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FOREWORD 


This standard was developed by the Consumer Technology Association’s R4 Video Systems 
Committee. 


CTA-861-H supersedes CTA-861-G and incorporates the Errata issued in September and 
November 2017 and July 2018, as well as the CTA-861.4 Updates to Dynamic HDR Metadata 
Signaling of March 2019 and CTA-861.5 Audio Format Extensions of September 2018. 
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A DTV Profile for Uncompressed High Speed Digital Interfaces 


1 SCOPE 


CTA-861 establishes protocols, requirements, and recommendations for the utilization of 
uncompressed digital interfaces by consumer electronics devices such as Digital Televisions 
(DTVs), digital cable, satellite or terrestrial set-top boxes (STBs), and related peripheral devices 
including, but not limited to DVD players/recorders, and other related Sources or Sinks. 


CTA-861 is applicable to a variety of standard DTV-related high-speed digital physical interfaces 
— such as Digital Visual Interface (DVI) 1.0 [4], Open LVDS Display Interface (LDI) [8], and High- 
Definition Multimedia Interface (HDMI) [110] specifications. Protocols, requirements, and 
recommendations that are defined include Video Formats and waveforms; colorimetry and 
quantization; transport of compressed and uncompressed, as well as Linear Pulse Code 
Modulation (L-PCM), audio; carriage of auxiliary data; and implementations of the Video 
Electronics Standards Association (VESA) Enhanced Extended Display Identification Data 
Standard (E-EDID) [9], which is used by Sinks to declare display capabilities and characteristics. 


CTA-861 adopters are strongly encouraged to implement High-bandwidth Digital Content 
Protection (HDCP) [3] content protection, defined by the Digital Content Protection, LLC (DCP) 
method, in order to be compatible with digital cable STBs as authorized by 47 C.F.R. § 76.602 
[108] and 47 C.F.R. §76.640 [109]. HDCP [3] permits viewing of high-value content that may be 
available from other video Sources in a home network. 
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2 GENERAL 


2.1 References 


CTA-861 includes mechanisms that allow a digital video Source (such as a cable, satellite or 
terrestrial STB, digital VCR, or DVD player) to supply displayable, baseband, digital video to High 
Definition Television (HDTV) devices, as well as peripheral devices such as repeaters, switchers, 
and recorders. 


2.1.1 Normative References 


The following standards contain provisions that, through reference in this text, constitute 
normative provisions of this standard. At the time of publication, the editions indicated were 
valid. All standards are subject to revision. Users of this standard are cautioned that a newer 
edition might or might not be compatible. 


2.1.1.1 Normative Reference List 


1. SMPTE ST 170:2004 (Archived 2010), Television — Composite Analog Video Signal — NTSC 
for Studio Applications, https://ieeexplore.ieee.org/document/7291416. 


2. SMPTE ST 274:2008, Television — 1920 x 1080 Image Sample Structure, Digital 
Representation and Digital Timing Reference Sequences for Multiple Picture Rates, 
https://ieeexplore.ieee.org/serviet/opac?punumber=7290127. 


3. DCP, L.L.C., High-bandwidth Digital Content Protection System, Revision 1.1, June 2003, 
https://www.digital-co.com/hdcp-specifications. 


4. DDWG, Digital Visual Interface, Revision 1.0, April 1999, 
https://web.archive.org/web/20120813201146/http%3A%2F%2Fwww.ddwg.org%2Flib%2F 


dvi_ 10.pdf. 


5. IEC 61966-2-4:2006+AMD1:2016 CSV, Multimedia systems and equipment — Colour 
measurement and management — Part 2-4: Colour management — Extended-gamut YCC 


colour space for video applications - xvYCC, https://webstore.iec.ch/. 


6. Recommendation ITU-R BT.601-7, Studio Encoding parameters of Digital Television for 
standard 4:3 and wide-screen 16:9 aspect ratios, March 2011, https://www.itu.int/rec/R- 
REC-BT.601/. 


7. Recommendation ITU-R BT.709-6, Parameter Values for the HDTV standards for production 
and International Programme Exchange, June 2015, https://www.itu.int/rec/R-REC-BT.709 


8. Open LVDS Display Interface (Open LD!) Specification, Version 0.95, May 1999, 
https://inova-semiconductors.de/files/daten/pdf/openldi.pdf (accessed October 29, 2020). 


9. VESA Enhanced Extended Display Identification Data (E-EDID) Standard, Release A, Revision 
1, February 2000, https://vesa.org/vesa-standards/. 


20. 


21. 


22. 


23. 
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. VESA Display Data Channel Command Interface (DDC/CI) Standard, Version 1.1, October 


2004, https://vesa.org/vesa-standards/. 


. ATSC Standard A/52:2018, Digital Audio Compression (AC-3, E-AC-3), January 2018, 


https://www.atsc.org/documents/. 


. IEC 60958-3:2006, Digital Audio Interface — Part 3: Consumer Applications with AMD1:2009 


and AMD2:2015, https://webstore.iec.ch/. 


. [EC 61909:2000, Audio recording — Minidisc system, https://webstore.iec.ch/. 
. IEC 61937-3:2017, Digital audio — Interface for non-linear PCM encoded audio bitstreams 


applying IEC 60958 — Part 3: Non-linear PCM bitstreams according to the AC-3 and 
enhanced AC-3 formats with AMD1:2020, https://webstore.iec.ch/. 


. IEC 61937-4:2003, Digital audio — Interface for non-linear PCM encoded audio bitstreams 


applying IEC 60958 — Part 4: Non-linear PCM bitstreams according to the MPEG audio 
formats, https://webstore.iec.ch/ 


. IEC 61937-5:2006, Digital audio — Interface for non-linear PCM encoded audio bitstreams 


applying IEC 60958 — Part 5: Non-linear PCM bitstreams according to the DTS (Digital 
Theater Systems) format(s) with AMD1:2019, https://webstore.iec.ch/. 


. IEC 61937-6:2006, Digital audio — Interface for non-linear PCM encoded audio bitstreams 


applying IEC 60958 — Part 6: Non-linear PCM bitstreams according to the MPEG-2 AAC and 
MPEG-4 AAC audio formats with AMD1:2014, https://webstore.iec.ch/. 


. IEC 61937-7:2004, Digital audio — Interface for non-linear PCM encoded audio bitstreams 


applying IEC 60958 — Part 7: Non-linear PCM bitstreams according to the ATRAC, ATRAC2/3 
and ATRAC-X formats with AMD1:2016, https://webstore.iec.ch/. 


. IEC 61937-8:2006, Digital audio — Interface for non-linear PCM encoded audio bitstreams 


applying IEC 60958 — Part 8: Non-linear PCM bitstreams according to the Windows Media 
Audio (WMA) Professional format, https://webstore.iec.ch/. 


IEC 61937-9:2017, Digital audio — Interface for non-linear PCM encoded audio bitstreams 
applying IEC 60958 — Part 9: Non-linear PCM bitstreams according to the MAT format, 
https://webstore.iec.ch/. 


IEC 61937-11, Digital audio — Interface for non-linear PCM encoded audio bitstreams 
applying IEC 60958 — Part 11: MPEG-4 AAC and its extensions in LATM/LOAS with 


AMD1:2018, https://webstore.iec.ch/. 


IEC 61937-12:2010, Digital audio — Interface for non-linear PCM encoded audio bitstreams 
applying IEC 60958 — Part 12: Non-linear PCM bitstreams according to the DRA formats, 
https://webstore.iec.ch/. 


ISO/IEC 11172-3:1993, Information Technology — Coding of moving pictures and associated 
audio for digital storage media at up to about 1.5 Mbit/sec, Part 3: Audio, 
https://webstore.iec.ch/. 
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26. 


27. 
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31. 


32. 


33. 


34. 


35. 


36. 


37. 


38. 


39. 


ISO/IEC 13818-3:1998, Information Technology — Generic coding of moving pictures and 
associated audio information, Part 3: Audio, https://webstore.iec.ch/. 


ISO/IEC 14496-3:2009, Information Technology — Coding of audio-visual objects — Part 3: 
Audio, https://webstore.iec.ch/. 


ISO/IEC 23003-1:2007, Information technology — MPEG audio technologies — Part 1: MPEG 
Surround with AMD2:2008 and COR1:2009, https://webstore.iec.ch/. 


DVD Forum, DVD Specifications for Read-Only Disc, Part 4, Audio Specifications, Version 1.0, 
Meridian Lossless Packing, https://www.dvdfllc.co.jp/. 


SCTE 127:2019, Carriage of Vertical Blanking Interval (VBI) Data in North American Digital 
Television Bitstreams, https://www.scte.org/download-scteisbe-standards/. 


Microsoft, WMA Pro Decoder Specification: An Overview of Windows Media Audio 
Professional decoder, 
http://www.microsoft.com/windows/windowsmedia/licensing/default.mspx. 


CTA-770.2-D, Standard Definition TV Analog Component Video Interface, 
https://cta.tech/Standards/. 


CTA-770.3-E, High Definition TV Analog Component Video Interface, 
https://cta.tech/Standards/. 


IEC 61966-2-5:2007, Multimedia systems and equipment — Colour measurement and 
management — Part 2-5: Colourmanagement — Optional RGB colour space — opRGB, 
https://webstore.iec.ch/. 


IEC 61966-2-1:1999, Multimedia systems and equipment — Colour measurement and 
management — Part 2-1: Colour management — Default RGB colour space — sRGB, 
https://webstore.iec.ch/. 


IEC 61966-2-1/Amendment 1:2003, Multimedia systems and equipment — Colour 
measurement and management — Part 2-1: Colourmanagement — Default RGB colour 
space — SRGB, https://www.iso.org/standard/35883.html. 


SMPTE ST 2016-1:2009, Format for Active Format Description and Bar Data, 
httos://www.smpte.org/standards/document-index/st. 


ETSI TS 102 114 v1.6.1, DTS Coherent Acoustics; Core and Extension with Additional Profiles, 
https://www.etsi.org/standards. 


ETSI TS 103 491 v1.2.1, DTS-UHD Audio Format; Delivery of Channels, Objects and Ambisonic 
Sound Fields, https://www.etsi.org/standards. 


ANSI INCITS 4-1986, Coded Character Sets — 7-Bit American National Standard Code for 
Information Interchange (7-Bit ASCII), Table 8, https://www.incits.org/. 


GB/T 22726-2008, Specification for multichannel digital audio coding technology, 
http://gbstandards.org/. 
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Recommendation ITU-R BT.2020-2, Parameter values for ultra-high definition television 
systems for production and international programme exchange, October 2015, 


https://www.itu.int/rec/R-REC-BT.2020/en. 


SMPTE ST 2084:2014, High Dynamic Range Electro-Optical Transfer Function of Mastering 
Reference Displays, https://www.smpte.org/standards/document-index/st. 


SMPTE ST 2086:2018, Mastering Display Color Volume Metadata Supporting High 
Luminance and Wide Color Gamut Images, https://www.smpte.org/standards/document- 


index/st. 


ISO/IEC 62574:2020, Audio, video and multimedia systems — General channel assignment 


of multichannel audio, https://webstore.iec.ch/. 


ISO/IEC 23008-3:2019, Information technology — High efficiency coding and media delivery 
in heterogeneous environments — Part 3: 3D audio, https://webstore.iec.ch/. 

ETSI TS 103 190 v1.1.1, Digital Audio Compression (AC-4) Standard, April 2014, 
https://www.etsi.org/standards. 

IEC 61937-13:2018, Digital audio — Interface for non-linear PCM encoded audio bitstreams 
applying IEC 60958 — Part 13: MPEG-H 3D Audio, https://webstore.iec.ch/. 

IEC 61937-14:2017, Digital audio — Interface for non-linear PCM encoded audio bitstreams 
applying IEC 60958 — Part 14: Non-linear PCM bitstreams according to the AC-4 format, 
https://webstore.iec.ch/. 

Recommendation ITU-R BT.2100-2, Image parameter values for high dynamic range 
television for use in production and international programme exchange, July 2018, 
https://www.itu.int/rec/R-REC-BT.2100. 

SMPTE ST 2113:2018, Colorimetry of P3 Color Spaces, 
https://www.smpte.org/standards/document-index/st. 

ETSI TS 103 433-1 v1.3.1, High-Performance Single Layer High Dynamic Range (HDR) System 
for use in Consumer Electronics devices; Part 1: Directly Standard Dynamic Range (SDR) 
Compatible HDR System (SL-HDR1), March 2020, https://www.etsi.org/standards. 
Recommendation ITU-T H.264, Advanced video coding, June 2019, 
https://www.itu.int/rec/T-REC-H.264. 

Recommendation ITU-T H.265, High efficiency video coding, June 2019 
https://www.itu.int/rec/T-REC-H.265. 

SMPTE ST 2094-1:2016, Dynamic Metadata for Color Volume Transform — Core 
Components, https://www.smpte.org/standards/document-index/st. 

SMPTE ST 2094-10:2016, Dynamic Metadata for Color Volume Transform — Application #1, 
https://www.smpte.org/standards/document-index/st. 

SMPTE ST 2094-40:2020, Dynamic Metadata for Color Volume Transform — Application #4, 
https://www.smpte.org/standards/document-index/st. 

Recommendation ITU-T T.35, Procedure for the allocation of ITU-T defined codes for non- 
standard facilities, February 2000, https://www.itu.int/ITU- 


T/recommendations/rec.aspx?rec=4840. 
VESA DisplayID Standard, Version 2.0, September 2017, https://vesa.org/vesa-standards 
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2.1.2 Informative References 


The following documents contain information that is useful in understanding this standard. At 
the time of publication, the editions indicated were valid. 


2.1.2.1 Informative Document List 
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ANSI/CTA-708-E, Digital Television (DTV) Closed Captioning, August 2013, 
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CTA-CEB16-B, Active Format Description (AFD) & Bar Data Recommended Practice, July 
2017, https://cta.tech/Standards/. 


ETSI TS 101 154 v1.11.1, Digital Video Broadcasting (DVB); Specification for the use of 
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2.2 Definitions 


For the purposes of CTA-861, the following definitions apply. 


2160p: A progressive CE Video Format with VIC in the range 93 through 107 and having 2160 
active vertical lines (Vactive) lines per Video Frame. 


Active Format Description (AFD): A data structure that describes what portion of the Picture 
actually contains useful information (e.g., letterbox and pillarbox Bars are not considered useful 
information). It is a 4-bit field like that standardized in Annex B of ETSI TS 101 154 [107], but 
whose exact meaning may depend on whether the data is delivered per ATSC/SCTE or ETSI 
standard. See Section 6.4 for details. Note that the use of the term “active” in this definition is 
not consistent with the use of this term in other portions of CTA-861 and most of the other 
documents referenced by CTA-861. 


Active Image: The useful portion of the image contained within a Picture. Active Image 
excludes letterbox and pillarbox Bars (see Annex N). 


Active Line: A Video Line occurring during the Vactive period(s) containing both Active Pixels 
and Blank Pixels. Active Pixels and Blank Pixels fill the Hactive and Hblank portions of these 
lines, respectively (see Annex N). 


Active Pixel: A Video Pixel that conveys Pixel Data (see Annex N). 


Auxiliary Video Information (AVI): Additional information (defined in CTA-861) related to the 
video being sent from a Source to a Sink. 


A/V: Audio and Video. 


Bar Data: Data that enable computation of regions of the image that are outside of the Active 
Image within a Picture, for example areas of zero or uniform luminance (i.e., Bars). 


Bar Pixel: An Active Pixel that conveys a portion of a Bar (see Annex N). 


Bars: Region of the display screen that is being driven or scanned at either zero luminance or at 
a uniform luminance; or regions of a Picture that are intended to be driven (e.g., matrix 
addressed) or scanned (e.g., cathode ray tube (CRT)) at either zero luminance or at a uniform 
luminance. In other words, it is the portion of the Picture that does not contain useful 
information (see Annex N). 


Basic Audio: Uncompressed, two channel, digital audio. Exact parameters are determined by 
the interface specification used with CTA-861 (e.g., 2 channel IEC 60958-3 [12] L-PCM, 32, 44.1, 
and 48 kHz sampling rates, 16 bits/sample). 


Blank Pixel: A Video Pixel that carries data other than Pixel Data (see Annex N). 


Blanking Line: A Video Line occurring during Vblank period(s) containing only Blank Pixels. 
Blank Pixels fill both Hactive and Hblank portions of these lines (see Annex N). 


Byte: 8 bits of data. 
CE Video Format: Any Video Format listed in Table 1 except the 640x480p Video Format. 


CTA-861-H 


Channel, Speaker: There is a direct relation between a Channel and a Speaker. Audio feeding 
into a Speaker is sent via a Channel. 


Color Component Sample: A value encoded using a Pixel Encoding that conveys a portion of the 
total color information about of a Video Pixel. A Color Component Sample might convey a red 
(R), green (G) or blue (B) color component, or might convey a luma component, or might 
convey a chroma component. A luma component, Y or |, represents luminance or intensity 
respectively, and a chroma component, C, represents a color difference. 


Color Space: a tristimulus representation of colors typically based on the CIE 1931 color 
matching functions 


Color Volume: space of all colors and intensities that a device or signal can reproduce or convey 


Colorimetry: combination of color gamut, color primaries, dynamic range, and color 
representation (e.g., YCgCr or RGB). Note that Transfer Function, Component Depth, 
Quantization Range, and chroma sample location can often vary for a specific colorimetry, 
although defaults and/or constraints for some of these might exist for some colorimetries. 


Component Depth: The number of bits used to represent a Color Component Sample. It is 
generally denoted as N. 


Compressed Audio: All audio formats other than L-PCM and One Bit Audio. 
Content Pixel: An Active Pixel that conveys a portion of the Active Image (see Annex N). 


CTA Extension: The E-EDID Standard [9] defines a VESA-assigned tag (0x02) that allows for an 
extension to be added with additional timing formats. 


CTA Video Format: Any Video Format listed in Table 1. 


Digital Television (DTV): A device that receives, decodes, and presents audio and video material 
that has been transmitted in a compressed form. The device can be a single unit or it can be 
constructed from a number of individual components (e.g., a digital terrestrial STB and an 
analog television). 


Direct Stream Transfer (DST): A lossless compression scheme for the Direct Stream Digital 
audio format. 


DTV: Defined in CTA-861 to be an HDTV or SDTV. A Sink can also be any combination of these 
terms. A DTV with an uncompressed video input is also considered a Sink. 


Dual-Aspect Ratio DTV: A DTV that simultaneously supports both Picture Aspect Ratios of a 
Video Format Timing (e.g., 720x480p). Listing both formats in the EDID data structure at the 
same time signifies simultaneous support. 


Dual-Aspect Ratio Timing: A Video Format Timing (e.g., 720x480p) that is available in both 
Picture Aspect Ratios (16:9 and 4:3) with no difference in the timing for the two formats. 


Electro-Optical Transfer Function (EOTF): A mathematical function that describes the 
relationship between the luminance values input to a display device and the values output by 
the display. 
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Frame Rate: Rate, normally in Hz, of sequence of video frames 
Full Range: R, G, B or Y Quantization Range that includes all code values. See Section 5.4. 


Graphics Overlay: Content, possibly semi-transparent, that is superimposed over and/or 
around the original video, typically by a set-top-box or video playback device. 


High Channel Count Audio (HCCA): Channel based audio that can be presented in speaker 
configurations greater than 7.1. For CTA-861, HCCA is limited to 32 channels. 


High Definition (HD): A CE Video Format that, inclusively, has 720 to 1080 active vertical lines 
(Vactive) lines per Video Frame. 


High Definition Television (HDTV): A DTV capable of displaying a 1920x1080i or 1280x720p 
Video Format in 16:9 Picture Aspect Ratio. See Section 3.2. 


IC7Cp: A Constant Intensity video signal format, where the | component represents intensity, 
and the Cr and Cp components represent color. This signal format can be sub-sampled in the 
Same manner as YCpCp. 


InfoFrame: A data transfer structure for sending miscellaneous information from a Source to a 
Sink over a CTA-861 interface. Varios InfoFrames are described in Section 6. 


Interface Development Organization (IDO): The organization (e.g., HDMI LLC, HDMI Forum, 
VESA) responsible for the CTA-861 implementation that is present. 


Interface VSIF: One or more VSIF(s) defined by the IDO. 


IRE Unit: A percentage of reference white with respect to black (i.e., blanking level). Reference 
white is assigned a value of 100, blanking a value of 0. 


IT Video Format: Any Video Format that is not a CE Video Format. Specifically, any Video 
Format not listed in Table 1 plus the 640x480p Video Format. 


Limited Range: R, G, B or Y Quantization Range that excludes some code values at the 
extremes. See Section 5.4. 


Multi-channel Audio: Digital audio with more than two channels, for example, L-PCM or AC-3. 


Native Display Device Aspect Ratio: Ratio of maximum width to height dimension of the 
addressable portion of a physical display device screen, which is indicated in the EDID version 1, 
revision 3 block’s “Max Horizontal Image Size” and “Max Vertical Image Size” fields. 


Native Video Resolution: The exact number of horizontal pixels and vertical lines (or pixel 
mapping) that matches the physical structure of the display device. 


Native Video Format: A Video Format with Native Video Resolution and scanning method that 
the display device accepts and displays without any internal scaling, de-interlacing, interlacing 
or frame rate conversion. 


Object Based Audio (OBA): In Object Based Audio, each sound is expressed as an Object with a 
3D position in space rather than a discrete number of channels or loudspeakers. 


One Bit Audio: 1-bit Sigma-Delta (Delta-Sigma) modulated signal stream. 
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opRGB: The optional RGB (opRGB) color space defined in IEC 61966-2-5 [32]. 


Opto-Electrical Transfer Function (OETF): A mathematical function that describes the 
relationship between scene light values received by a camera (adjusted for exposure) and 
values that represent the captured video signal. 


opYCCeo1: The luma-chroma-chroma (YCC) color space defined in Annex A of IEC 61966-2-5 [32]. 
The Rec. ITU-R BT.601 [6] color conversion matrix is used to transform RGB values to YCC 
values. 


Picture: An uncompressed video signal representing a rectangular array of pixels containing an 
image that may, in whole or part, be rendered onto a display. A Picture refers to the Pixel Data 
transferred in the uncompressed video signal during a single Video Frame. A Picture includes 
both the Active Image and Bars (see Annex N). The implementation of CTA-CEB16 [106] Total 
Image on the CTA-861 interface. 


Picture Aspect Ratio: Ratio of width to height dimension of the Picture as delivered across the 
uncompressed digital interface, including any top, bottom, or side Bars. Only four Picture 
Aspect Ratios are specified for this interface: 4:3, 16:9, 64:27, and 256:135 (see Annex N). 


Picture Line: The complete set of contiguous Active Pixels along a single Active Line, where each 
Active Pixel contains a portion of either the Active Image or a Bar. 


Picture Pixel: A single Active Pixel within a Picture Line containing a portion of either the Active 
Image ora Bar. 


Pixel Data: Color Component Samples transmitted over the interface during a single Active 
Pixel. These samples may, but need not, completely define a single Video Pixel. 


Pixel Encoding: Colorimetry in conjunction with a Component Depth, Transfer Function, 
Quantization Range, and chroma sample location (if applicable) used to represent the colors of 
transmitted or received pixels. 


Preferred Picture Aspect Ratio: In a Dual-Aspect Ratio DTV, the preferred aspect ratio of a 
given Video Format Timing (e.g., 720x480p) is the aspect ratio of the first such timing listed in 
the EDID data structure (see Section 4.1). This would be the Picture Aspect Ratio that would be 
displayed if a DTV were to receive a Video Format Timing with no accompanying Picture Aspect 
Ratio information (i.e., no AVI sent from Source). 


Preferred Video Format: The Video Format that a display manufacturer determines provides 
optimum image. 


Note: Source implementers are encouraged to review Section 7.2.2 for related 
guidance. 


Quantization Range: The range of code values used to represent the color components of 
Active Pixels when transitioning between color extremes (e.g., black to white). 


Resolution: Horizontal and vertical active pixel count of a video frame 
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RGB: A general representation of an analog or digital component video signal, where R 
represents the red color, G represents green, and B represents blue; and each component is 
sampled at a uniform rate (4:4:4). For the purpose of CTA-861, the signal is digital. 


Sink: A device, which receives an uncompressed A/V signal. 
Source: A device, which generates an uncompressed A/V signal. 


Source Pass-through Mode: A mode supported by some media-based Sources, wherein 
decompressed video passes directly (in its original format) to a Sink without interlacing, 
deinterlacing, scaling, or frame rate conversion. 


SRGB: The default RGB color space defined in IEC 61966-2-1 [33]. 


Standard Definition (SD): A CE Video Format that has less than 720 active vertical lines 
(Vactive) lines per Video Frame (e.g., 480 or 576 active vertical lines). 


Standard Definition Television (SDTV): A DTV capable of displaying 720x480i'! or 720x576i 
video in at least one of two Picture Aspect Ratios, 16:9 or 4:3. 


sYCC601: The luma-chroma-chroma (YCC) color space defined in Annex F of IEC 61966-2- 
1/Amendment 1 [34]. The Rec. ITU-R BT.601 [6] color conversion matrix is used to transform 
RGB values to YCC values. s¥YCC¢o1 color space can represent colors outside of the sRGB color 
gamut. 


Transfer Function: Non-linear mathematical function that maps linear light levels to values 
representing a video signal or vice versa. Transfer functions include EOTF, inverse EOTF, OETF, 
and inverse OETF. 


Uncompressed Audio: Linear Pulse Code Modulated (L-PCM) and One Bit Audio. 


Unique Active Pixel: A timing pattern, consisting of either fractional, single, or multiple 
contiguous Active Pixels, that effectively increases or lowers horizontal resolution (see Annex 
O). By splitting each Active Pixel into two Unique Active Pixels (e.g., using YCgCr 4:2:0 sampling), 
the effective horizontal resolution can be doubled. Alternately, Unique Active Pixels consisting 
of one or more contiguous Active Pixels having the same (systematically repeated) Pixel Data 
can be used to lower horizontal resolution. In this case, the number of Active Pixels in a Unique 
Active Pixel is equal to the pixel repetition factor (PR+1). 


Unique Content Pixel: A timing pattern consisting of one or more contiguous Content Pixels 
having the same (systematically repeated) Pixel Data. 


Video Field: The period from the leading (active) edge of one vertical sync (Vsync) pulse to the 
Same edge of the next Vsync pulse or the timing pattern associated with that period. 


Video Format: A Video Format is sufficiently defined such that when it is received at the DTV, 
the Sink has enough information to properly display an image. Although it is generally 


1 Content is encoded as 704x480 or 720x483 
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acceptable to define a Video Format by specifying only a Video Timing and a Picture Aspect 
Ratio, a more complete definition requires additional information including a Color Space, a 
Quantization Range, and a Component Depth (N). 


Video Format Timing (or Video Timing): The resolution and frame rate associated with a Video 
Format. Note that a specific Video Format Timing may be associated with more than one Video 
Format (e.g., 720x480p formatted in the 4:3 Picture Aspect Ratio or a 720x480p formatted in 
the 16:9 Picture Aspect Ratio). 


Video Frame: The period (beginning and ending where the active edges of horizontal and 
vertical sync align) for vertical total lines to elapse or the repetitive timing pattern associated 
with that period. Interlaced timings have two Video Fields per Video Frame, while progressive 
timings have only one. Therefore, in the case of progressive timings, the terms “video field” and 
“video frame” are synonymous. 


Video Identification (ID) Code: An integer value used to identify a particular Video Format 
listed in Table 3. Table 1 and Table 2 use Video Identification Codes to cross reference a 
particular Video Format with its exact Video Timing. 


Video Line: The period, lasting Htotal pixel clock periods, beginning and ending with the active 
edge of a horizontal sync pulse (Hsync). The term may also refer to a timing pattern that occurs 
during this period consisting of Htotal contiguous Video Pixels. 


Video Pixel: The period delimited by two sequential pixel clock active edges. The term may also 
refer to the portion of a timing pattern where the interface transfers one unit of data. The unit 
of data transferred may be related to a single pixel or other information (e.g., Audio) and may 
convey the same information as the preceding Video Pixel. 


xvYCCe01: The extended gamut luma-chroma-chroma (YCC) color space defined in IEC 61966-2-4 
[5]. The Rec. ITU-R BT.601 [6] color conversion matrix is used by IEC 61966-2-4 [5] to transform 
RGB values to YCC values. The extent of the gamut is device dependent. 


xvYCC709: The extended gamut luma-chroma-chroma (YCC) color space defined in IEC 61966-2- 
4 [5]. The Rec. ITU-R BT.709 [7] color conversion matrix is used by IEC 61966-2-4 [5] to 
transform RGB values to YCC values. The extent of the gamut is device dependent. 


YCsCr: A general representation of a digital component video signal, where Y represents 
luminance, Cg represents the color blue, and Ce represents red; the color component may be 
sub-sampled at half the rate as luminance (4:2:2) or may be sampled at a uniform rate (4:4:4). 
For the purposes of CTA-861, it may be considered a digital representation of YPpPr. 
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2.3 Symbols and Abbreviations 


AAC 
ADB 
AFD 
AMOL96 
ANSI 
AR 
ATRAC 
A/V 
AV/C 
AVI 

BD 
BDA 
CD 
CDB 
CID 
CRT 
CTA 
DAC 
DBS 
DCP 
DDWG 
DMT 
DRA 
DSC 
DST 
DTD 
DTV 
DVC 
DVD 
D-VHS 


Advanced Audio Coding 

Audio Data Block 

Active Format Description 
Automated Measurement of Lineups 96 (bits/field) 
American National Standards Institute 
Aspect Ratio 

Adaptive Transform Acoustic Coding 
Audio/Video 

Audio/Video Control 

Auxiliary Video Information 

Blu-Ray Disc 

Blu-ray Disc Association 

Compact Disk 

Colorimetry Data Block 

IEEE Company Identifier 

Cathode Ray Tube 

Consumer Technology Association 
Digital to Analog Converter 

Direct Broadcast Satellite 

Digital Content Protection 

Digital Display Working Group 
Display Monitor Timing 

Digital Rise Audio 

Digital Still Camera 

Direct Stream Transfer 

Detailed Timing Descriptor 

Digital Television 

Digital Video Camera 

Digital Versatile Disk 

Digital VHS 
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DVI 
E-DDC 
E-EDID 
ELB 
EOTF 
ETB 
EUI 
FFP 
HCCA 
HD 
HDCP 
HDD 
HD DVD 
HDMI 
HDR 
HDR DMDB 
HDR SMDB 
HDTV 
HLG 
HPD 
IDO 
IEC 
IEEE 
IFDB 
IRE 
ISO 
ITU 
LCD 
LDI 
L-PCM 
LSB 


Digital Visual Interface 

Enhanced Display Data Channel 

Enhanced Extended Display Identification Data Standard 
End of Left Bar 

Electro-optical Transfer Function 

End of Top Bar 

Extended Unique Identifier 

Fractional Fixed Point 

High Channel Count Audio 

High Definition 

High-bandwidth Digital Content Protection 
Hard Disk Drive 

High Definition DVD 

High-Definition Multimedia Interface 

High Dynamic Range 

HDR Dynamic Metadata Data Block 

HDR Static Metadata Data Block 

High Definition Television 

Hybrid Log-Gamma 

Hot Plug Detect 

Interface Development Organization 
International Electrotechnical Commission 
Institute of Electrical and Electronics Engineers 
InfoFrame Data Block 

Institute of Radio Engineers 

International Organization for Standardization 
International Telecommunications Union 
Liquid Crystal Display 

LVDS Display Interface 

Linear Pulse Code Modulation 


Least Significant Bit 
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LVDS 
MAT 
MaxCLl 
MaxFALL 
MPEG 
MSB 
NABTS 
OBA 
OpenLDI 
OUI 
PES 
PLP 
PMP 
PQ 
RCD 
RCDB 
SACD 
SADB 
SBB 
SD 
SDTV 
SLDB 
SMPTE 
SPM 
SRB 
STB 
SVD 
SVR 
TVG2X 
VBI 
VCDB 
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Low Voltage Differential Signaling 

MLP Audio Transport 

Maximum Content Light Level 

Maximum Frame-average Light Level 
Moving Picture Experts Group 

Most Significant Bit 

North American Basic Teletext Specification 
Object Based Audio 

Open LVDS Display Interface 
Organizationally Unique Identifier (Note: CID may be used as an alternative) 
Packetized Elementary Stream 

Primary Listening Position 

Portable Media Player 

Perceptual Quantization 

Room Configuration Descriptor 

Room Configuration Data Block 

Super Audio CD 

Speaker Allocation Data Block 

Start of Bottom Bar 

Standard Definition 

Standard Definition Television 

Speaker Location Data Block 

Society of Motion Picture & Television Engineers 
Speaker Presence Mask 

Start of Right Bar 

Set-Top Box 

Short Video Descriptor 

Short Video Reference 

TVGuide 2X (bitrate) 

Vertical Blanking Interval 


Video Capability Data Block 
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VCR 

VDB 

VESA 

VESA DDDB 
VESA DTCDB 
VFPDB 

VIC 

VSADB 
VSDB 

VSIF 
VSVDB 
WMA Pro 
Y420CMDB 
Y420VDB 


Video Cassette Recorder 

Video Data Block 

Video Electronics Standards Association 
VESA Display Device Data Block 

VESA Display Transfer Characteristic Data Block 
Video Format Preference Data Block 
Video Identification (ID) Code 
Vendor-Specific Audio Data Block 
Vendor-Specific Data Block 
Vendor-Specific InfoFrame 
Vendor-Specific Video Data Block 
Windows Media Audio Professional 
YCgCr 4:2:0 Capability Map Data Block 
YCgCr 4:2:0 Video Data Block 
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2.4 Compliance Notation 
As used in this document, “shall” denotes mandatory provisions of the standard. “Should” 
denotes a provision that is recommended but not mandatory. “May” denotes a feature whose 
presence does not preclude compliance and implementation of which is optional. “Optional” 
denotes items that may or may not be present in a compliant device. 


2.5 Hexadecimal Notation 


The characters Ox preceding numbers or letters A through F designate the following values as 
hexadecimal notation. 


2.6 HxV Video Timing Notation 


Video Timings are sometimes expressed using HxV notation (e.g., “720x480”), where H and V 
are equal to the number of Active Pixels per Active Line and the number of Active Lines per 
Video Frame, respectively. The H value is sometimes surrounded by parenthesis and preceded 
by the number of Unique Active Pixels. Example: “720(1440)x480”. In this example, a Unique 
Active Pixel is formed by systematically repeating the preceding Active Pixel PR-number of 
times such that the effective horizontal resolution is lower than the value indicated in the 
parentheses by a factor of 1/(PR+1) (see Table 1, Note 2 for details). 

Video Timings may also be expressed using the HxV @ F notation (e.g., “720x576i @ 50 Hz “), 
where a value F is appended to denote field frequency. The value F also refers to the Video 
Frame rate when the letter to the right of the value V is a ‘p’. North American Video Timings 
usually have a slash ‘/’ in the name (e.g., “720x480i @ 59.94/60 Hz”) to delimit dual vertical 
frequencies. Here, the first vertical frequency is adjusted by a factor of exactly 1000/1001 (for 
NTSC broadcast compatibility) relative to the second (see Table 1, Note 3). 


2.7 Bit Naming Conventions 


The names of the individual bits of multi-bit data values are composed using a value’s 
mnemonic followed by a bit number. The significance of each bit is indicated by the bit number 
according to little-endian convention (i.e., bit number 0 is the least significant). For example, 
the quantization value is given the mnemonic ‘Q’, which is associated with two bits named ‘Q1’ 
and ‘QO’. When the value Q=2, bit Q1=1 and bit QO=0. 


Future bits are a special case. These bits begin with the mnemonic ‘F’ followed by a bit number. 
In this case, bit numbers indicate location — not significance. Future bits shall be set to zero 
and ignored. 


2.8 ASCII Codes, Characters & Strings 


ASCII characters shall be encoded using either 7-bit or 8-bit codes as indicated. The least 
significant 7-bits shall encode characters according to ANSI INCITS [38], where ANSI INCITS bits 
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b1 through b7 are mapped to bits 0 through 6, respectively. In the case of 8-bit codes, the msb 
(bit 7) shall always be set to zero. 
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3 OVERVIEW 


CTA-861 describes requirements for video Sources and Sinks that include an uncompressed, 
baseband, digital video interface. These requirements apply to any baseband digital video 
interface that makes use of VESA E-EDID (structures for discovery of supported Video Formats) 
[9] and supports 24-bit RGB. The 60 Hz/59.94 Hz Video Timings are based on analog formats 
already standardized in CTA-770.2 [30] and CTA-770.3 [31]. A preferred physical/link interface is 
not specified in CTA-861. See the annexes on how to apply CTA-861 to the individual interfaces 
available at the time of this writing. Digital Visual Interface (DVI 1.0) [4] and OpenLDI 0.95 [8] 
can be used to enable minimal digital interface functionality. To take advantage of these 
enhancements, the physical interface also needs a way to transport CTA InfoFrames, digital 
audio, and YCgCr pixels from the Source to the Sink. The High-Definition Multimedia Interface 
(HDMI) [110] is capable of taking advantage of these enhancements. 


Enhanced Extended Display Identification Data (E-EDID) was created by VESA to enable plug 
and play capabilities of Sinks. This data, which would be stored in the Sink, describes Video 
Formats that the Sink is capable of receiving and rendering. The information is supplied to the 
Source, over the interface, upon the request of the Source. The Source then chooses its output 
format, taking into account the format of the original video stream and the formats supported 
by the Sink. The Source (e.g., STB) is responsible for the format conversions necessary to supply 
video in an understandable form to the Sink. 


CTA-861 includes the Sink’s ability to describe other capabilities in the E-EDID — in addition to 
supported Video Formats (e.g., digital audio). In those cases, the same basic mechanism applies 
(i.e., the Source reads EDID data in the Sink to determine its capabilities and then the Source 
sends only audio and Video Formats the Sink is capable of receiving). 


The physical/link standards in Annex B, Annex C and Annex D do not support transport of closed 
captioning (CTA-608-C [104] and CTA-708-C [105]); therefore, the Source processes these 
elements. Specifically, if closed captioning is to be displayed, it is decoded by the Source, 
inserted into the video, and displayed as open captions. Similarly, if system Information, 
program information, events, service descriptors, etc. are displayed, related graphical 
information is inserted into the video by the Source. Control of closed captioning settings, 
programs, events, etc. is a feature of the Source, not supported by this interface and beyond 
the scope of CTA-861. 


Furthermore, content advisory user menus, settings, and blocking are accommodated in the 
Source, and are beyond the scope of CTA-861. 


3.1 General Video Format Requirements for Sources 
A Source shall support at least one of the following Video Timings: 


e 640x480p @ 59.94/60Hz 
e 720x480p @ 59.94/60Hz 
e 720x5/6p @ 50Hz 
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A Source that accepts 60Hz Video Formats, and that supports HDTV capability, should support 
720x480p @ 59.94/60Hz and 1280x720p @ 59.94/60Hz or 1920x1080i @ 59.94/60Hz Video 
Format Timings. 


A Source that accepts 50Hz Video Formats, and that supports HDTV capability, should support 
720x576p @ 50Hz and 1280x720p @ 50Hz or 1920x1080i @ 50Hz Video Format Timings. 


3.2 General Video Format Requirements for Sinks 


A Sink that accepts 60Hz Video Formats shall support the 640x480p @ 59.94/60Hz and 
720x480p @ 59.94/60Hz Video Format Timings. 


A Sink that accepts 50Hz Video Formats shall support the 640x480p @ 59.94/60Hz and 
720x576p @ 50Hz Video Format Timings. 


A Sink that accepts 60Hz Video Formats, and that supports HDTV capability, shall support 
1280x720p @ 59.94/60Hz or 1920x1080: @ 59.94/60Hz Video Format Timings. 


A Sink that accepts 50Hz Video Formats, and that supports HDTV capability, shall support 
1280x720p @ 50Hz or 1920x1080i @ 50Hz Video Format Timings. 


A Sink that supports 640x480p @ 59.94/60Hz shall support video formatted in a 4:3 Picture 
Aspect Ratio, as described in Section 4.1, and coded with the default Component Depth, 
colorimetry, and Quantization Range for IT Video Timing as specified in Section 5.1, when 
receiving such timing. 


A Sink that supports 720x480p @ 59.94/60Hz or 720x576p @ 50Hz should support video 
formatted in either 4:3 or 16:9 Picture Aspect Ratio, as described in Section 4.1, and coded with 
the default Component Depth, colorimetry, and Quantization Range for CE Video Timing as 
specified in Section 5.1, when receiving such timings. 


22 


CTA-861-H 


4 VIDEO FORMATS AND WAVEFORM TIMINGS 


CTA-861 interfaces transport uncompressed digital video using a variety of CE and IT Video 
Timings. This section describes the default IT 640x480 Video Timing as well as all of the 
standard CE Video Timings. The balance of IT timings are documented in the VESA DMT [124], 
GTF [120, 123], and VESA CVT [117, 121] standards. 


Throughout CTA-861, the term “Video Format Timing” does not include aspect ratio, whereas 
the term “Video Format” does encompass the aspect ratio. 


A Video Timing with a vertical frequency that is an integer multiple of 6.00 Hz (i.e., 24.00, 30.00, 
60.00, 120.00 or 240.00 Hz) is considered to be the same as a Video Timing with the equivalent 
detailed timing information but where the vertical frequency is adjusted by a factor of 
1000/1001 (i.e., 24/1.001, 30/1.001, 60/1.001, 120/1.001 or 240/1.001). That is, they are 
considered two versions of the same Video Timing but with slightly different pixel clock 
frequencies. Therefore, a DTV that declares it is capable of displaying a Video Timing with a 
vertical frequency that is either an integer multiple of 6 Hz or an integer multiple of 6 Hz 
adjusted by a factor of 1000/1001 shall be capable of displaying both versions of the Video 
Timing. 

The additional low-resolution progressive Video Format Timings (1440x240p, 2880x240p, 
1440x288p, and 2880x288p) consist of one of several frame formats. These frame formats 
differ only by one or two scan lines in the vertical blanking interval. For that reason, they are 
treated as the same Video Format with a slight variation in the parameters (i.e., handled ina 
way similar to the 59.94Hz/60Hz formats). For this reason, if a Sink declares support of one of 
these Video Formats of a specific Picture Aspect Ratio (through EDID), then it shall support all 
variations of that Video Format of the same Picture Aspect Ratio. 


The mandatory and optional formats defined in CTA-861 shall comply with the timing 
parameters in Table 1 and Table 2. 


In Table 2, note that the Vfront, Vsync, and Vback values are defined in terms of Video Lines 
(see Section 2.2 “Video Line”). The reader is advised that the signals Hsync, Vsync, Data Enable, 
and Clock are encoded in an interface-specific manner. For details, see the specifications for 
DVI [4], OpenLDI [8] or HDMI [110]. 


Standard-definition Video Timings generally use negative vertical and horizontal sync, while 
high-definition Video Timings use positive. 


Lines are always numbered sequentially from 1 to Vtotal and match the line numbers found in 
the given reference standard. In the case of high-definition Video Timings, the leading-line of 
vertical sync in field 1 is always line 1. In the case of standard-definition Video Timings, line 1 
may coincide with the leading-line of vertical sync in field 1 or a line slightly before it. CTA-861 
Video Timings are sometimes based on legacy 60Hz standard-definition television standards 
that have slightly larger Vactive values (e.g., 483-lines vs. 480-lines). Such Video Timings begin 
line numbering before the leading-line of vertical sync in field 1 — in order to keep line- 
numbers in alignment with the legacy standard. The “Ln” column in Table 2 provides the line 
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number of the leading-line of vertical sync in field 1 for each Video Timing code. See Annex L for 
examples. 


For progressive Video Timings and Field 1 of interlaced Video Timings, the leading (active) edge 
of Hsync and Vsync transitions shall be perfectly aligned plus or minus zero pixel clocks. In Field 
2 of interlaced Video Timings, the alignment between the leading (active) edge of Hsync and 
Vsync transitions shall be precisely a half-line (Htotal/2) plus or minus zero pixel clocks. 
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Table 1 - Video Format Timings — Detailed Timing Information 


Vactive Hblank°? Vtotal Vblank> 


1/P 


1280 720 Prog 


H Freq? 


3300 2020 750 


OW 


18.000 


1280 720 Prog 3960 2680 750 30 18.750 


1280 720 Prog 3300 2020 750 


Ww 
je) 


22.500 


2500 1220 750 


je) 


36.000 


1280 720 Prog 


1920 1080 Prog 2750 830 1125 45 27.000 


1920 1080 Prog 2640 720 1125 45 28.125 


1920 1080 Prog 2200 280 1125 45 33.750 


1920 1080 2750 830 1125 4 


ul 


Prog 54.000 


oO 


1680 720 Prog 3300 1620 75 18.000 


1680 720 Prog 3168 1488 750 


168) 


0 18.750 


—N 
ui 
oO 
OW 


Ww Ww Ww 


1680 720 Prog 2640 22.500 


1680 720 Prog 2750 1070 750 


jo) 


36.000 


2560 1080 Prog 3750 1190 1100 2 26.400 


2560 1080 Prog 3200 1125 45 28.125 


2560 1080 Prog 3520 1125 45 33.750 


2560 1080 Prog 3750 1190 1100 20 52.800 


3840 2160 Prog 5500 1660 2250 54.000 


3840 2160 Prog 5280 1440 2250 56.250 
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4096 2160 Prog 5500 1404 2250 54.000 


4096 2160 Prog 5280 1184 2250 56.250 
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Table 1 - Video Format Timings — Detailed Timing Information (continued) 


Hblank? Vtotal Vblank° H Freq? 
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Pixel Freq? 
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Table 1 - Video Format Timings — Detailed Timing Information (continued) 


[as [m0 | 576 | roe | ame | me | os | | caso | son00 | samo 
[air [ 00 [2160 | Prog | sze0 [reso | 2250 | oo | 2asaw | 10000 | 1166000 
[sr [sao 2160 | Poe | ee00 [1480 | 2050 [ a0 | 225000 | 10000 | 1485000 
[218 [+008 [2160 | Prop | somo [vse | 050 | 00 | 22500 | 10000 | 1188000 
[¥ie,120 [| aeao [2160 | Prop | «too [seo | 2050 | oo | 2roow | 2000" | r1ee000 
[ss [sao [2160 | Prop | ss00 | aeo | 050 | oo | 27a | 2000" | 1485000 
[26 [405 [2160 | Prog | s1o0 [aoe | 2250 | 20 | aro | 2000" | 1186000 


[sass | vm | sr | ros | oe | om | os | © | 5000 | wom | soem 
Tees | wo | se | me | ame | ome | a | ms | caso | mom | com 
a 
[—se.50 | wo [| me [me | me [os | ms | amr | mare | mom 


1. Vblanking — Fractional values indicate that the number of Blanking Lines varies (see timing diagram for more details). 

2. The pixels for the 720(1440)x480i@59.94/60Hz, 720(1440)x240p@59.94/60Hz, 720(1440)x576i@50Hz, and 720(1440)x288p@50Hz Video Formats are double clocked to 
meet minimum speed requirements of the interface, thus H active is shown as 1440, instead of 720. At higher field rates, these formats continue to be double clocked — 
even though double clocking is unnecessary. Each pixel of the 1440xN 480p and 576p formats, as well as the 2880xN 480i, 240p, 480p, 576i, 288p, and 576p formats, is 
repeated a variable number of times. The repeat value is communicated using the AVI InfoFrames (see Section 6.4). 

3. A Video Timing with a vertical frequency that is an integer multiple of 6.00 Hz (i.e., 24.00, 30.00, 48.00, 60.00, 120.00 or 240.00 Hz) is considered to be the same as a Video 
Timing with the equivalent detailed timing information but where the vertical frequency is adjusted by a factor of 1000/1001 (i.e., 24/1.001, 30/1.001, 60/1.001, 120/1.001 or 
240/1.001). That is, they are considered two versions of the same Video Timing but with slightly different pixel clock frequencies. The vertical frequencies of the 240p, 480p, 
and 480i Video Formats are typically adjusted by a factor of exactly 1000/1001 for NTSC video compatibility, while the 576p, 576i, and the HDTV Video Formats are not. The 
VESA DMT standard [124] specifies a + 0.5% pixel clock frequency tolerance. Therefore, the nominally 25.175 MHz pixel clock frequency value given for Video Identification 
Code 1 may be adjusted to 25.2 MHz to obtain an exact 60 Hz vertical frequency. 

4. To avoid fractional frame rate conversions in Source and Sinks, Sources should use the exact vertical frequencies of 25.000 Hz, 50.000 Hz, 100.000 Hz, 120.000 Hz, 200.000 
Hz, and 240.000 Hz at 25 Hz, 50 Hz, 100 Hz, 120 Hz, 200 Hz, and 240 Hz, respectively. Likewise, Sources should use the exact vertical frequencies of (24 * 1000) / 1001 Hz, (30 
* 1000) / 1001 Hz, (48 * 1000) / 1001 Hz, (60 * 1000) / 1001 Hz, (120 * 1000) / 1001 Hz, and (240 * 1000) / 1001 Hz at 23.98 Hz, 29.97 Hz, 47.95 Hz, 59.94 Hz, 119.88 Hz, 
239.76 Hz, respectively. 

5. Data in this column is provided for informational purposes only. 
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Table 2 - Video Format Timings — Detailed Sync Information 
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Table 2 - Video Format Timings — Detailed Sync Information (continued) 
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Table 2 - Video Format Timings — Detailed Sync Information (continued) 
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1. The reference standard uses tri-level sync, while CTA-861 uses bi-level. Bi-level sync timing is accomplished using the second half of the reference standard’s tri-level sync, 
defining the actual sync time to be the rising edge of that pulse. 


2. The reference standard uses a composite sync while CTA-861 uses separate sync signals, thus eliminating the need for serrations during vertical sync. 
3. VESA defines blanking as not including the border while CTA-861 includes the border within the blanking interval. 
4. Uses default IT color space, RGB components, and Full Range 8-bit color coding & quantization (see Section 5.1). 
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Table 2 - Video Format Timings — Detailed Sync Information (continued) 


5. Is specifically designed for use with 31.25 kHz constant horizontal rate cathode-ray tube televisions and has a total of 1250 vertical lines — instead of the normal 1125 
found in SMPTE ST 274 based timings. It has a frame, which is split into two unequal fields of 624.5 and 625.5 lines. The Video Format is specifically designed for use with 
special 31.25 kHz constant horizontal rate cathode-ray tube televisions and should be used with caution. Timing is similar to the 1250/50/2:1 system that described in 
Australian AS 4933.1-2005 standard [126]. 


6. Same as the reference standard except for horizontal and vertical synchronization pulse durations, which are specified in Rec. ITU-R BT.711-1 [115] and Rec. ITU-R BT.1700 
[113]. Thus, the clock is 27 MHz. 


7. There are two or three Video Frame timings that differ only in the number of Blanking Lines in the vertical blanking interval of the frame. All are considered variations of 
the same Video Timing. 


8. Represents a superset of game console timings with variable repetition factors. Encompasses all of the following cases: 
a) 2880/10=288 pixels/line 
b) 2880/8=360 pixels/line 
c) 2880/7=411 pixels/line 
d) 2880/5=576 pixels/line 
e) 2880/4=720 pixels/line 
Typically has Bars on the left and right sides that are 160/n pixels wide, where n is the repetition factor. 
9. Represents a superset of timings with specific repetition factors that provide either additional bandwidth for carrying audio data or increased horizontal video resolution. 
10. Is a superset of Video Formats encompassing all of the following cases: 
a) 1440/2=720 pixels/line 
b) 1440/1=1440 pixels/line 
11. Is a superset of Video Formats encompassing all of the following cases: 
a) 2880/4=720 pixels/line 
b) 2880/2=1440 pixels/line 
c) 2880/1=2880 pixels/line 
12. The exact Video Timing depends upon the pixel repetition factor specified in the AVI InfoFrame. 


13. If this Video Timing is advertised in the EDID, the Sink shall have an interface capable of signaling pixel repetition via AVI InfoFrames (e.g., HDMI) and shall accept all 
listed pixel repetition factors. 


14. It is likely that non-HDMI Sources may not recognize this Video Format in a Detailed Timing Descriptor. 

15. Assumes the pixels are double-clocked to meet minimum clock speed requirements for the interface. 

16. Assumes the pixels are double-clocked. 

17. This is a “gaming” format. Progressive timing is obtained by removing the second field of the reference standard’s interlaced timing. 


18. Hpol and Vpol stand for horizontal and vertical sync pulse polarity, respectively. The value ‘N’ signifies negative polarity, where the signal stays mostly high (at a logic ‘1’) 
and only pulses low (to a logic ‘0’) during the sync pulse. Likewise, the value ‘P’ signifies positive polarity, where the signal stays mostly low (at a logic ‘0’) and only pulses 
high (to a logic ‘1’) during the sync pulse. 


19. Vfront varies as a function of Vtotal. 
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Table 2 - Video Format Timings — Detailed Sync Information (continued) 


20. This value applies when Vtotal is 262 lines. 
21. This value applies when Vtotal is 263 lines. 
22. This value applies when Vtotal is 312 lines. 
23. This value applies when Vtotal is 313 lines. 
24. This value applies when Vtotal is 314 lines. 


25. This Video Timing has been modified from the one listed in the reference standard. The reference standard specifies an odd Htotal greater than 4096, which is 
incompatible with legacy silicon. CTA-861 instead uses the referenced standard’s 720p30 Video Timing with a reduced pixel clock frequency to obtain 24Hz. 


26. This Video Timing has been modified from the one listed in the reference standard. The pixel rate and Hfront have 

been modified to provide Hactive of 1680 pixels needed to achieve a 64:27 Picture Aspect Ratio with approximately square (64:63) pixels. 
27. This Video Timing has been modified from the one listed in the reference standard. The pixel rate and Hfront have 

been modified to provide Hactive of 2560 pixels needed to achieve a 64:27 Picture Aspect Ratio with perfectly square pixels. 

28. Data in this column is provided for informational purposes only. 


29, Using UHDTV1 image sample structures and frame rates from SMPTE ST 2036-1:2009 [136]. 


30. Using UHDTV1 image sample structures and frame rates from SMPTE ST 2048-1:2011 [137]. 


31. This Video Timing has been modified from the one listed in the reference standard. The pixel rate and Hfront have 
been modified to provide Hactive of 5120 pixels needed to achieve a 64:27 Picture Aspect Ratio with perfectly square pixels. 
32. This Video Timing has been modified from the one listed in the reference standard. The pixel rate and Hfront have 


been modified to provide Hactive of 10240 pixels needed to achieve a 64:27 Picture Aspect Ratio with perfectly square pixels. 
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Figure 1 - General Progressive Video Format Timing (Negative Sync) 
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Figure 2 - General Progressive Video Format Timing (Positive Sync) 
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Figure 3 - General Interlaced Video Format Timing (Negative Sync) 
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Figure 4 - General Interlaced Video Format Timing (Positive Sync) 
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Figure 5 - Special Interlaced Video Format Timing (Even Vtotal) 
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4.1 Aspect Ratio 


A DTV should always indicate its native (physical) aspect ratio in the EDID version 1, revision 3 
block’s “Max Horizontal Image Size” and “Max Vertical Image Size” fields even if the maximum 
image size is unknown or variable. Typically, the ratio of these two fields is 4:3, 16:9, or 64:27 — 
though this may not be true for some displays with non-standard aspect ratios. The Source 
should use these fields to determine the Native Display Device Aspect Ratio. 


The 480p, 480i, 240p, 576p, 576i, and 288p Video Formats are available in two different aspect 
ratios (4:3 and 16:9). The 720p, 1080p, and certain? 2160p Video Formats are also available in 
two different aspect ratios (16:9 and 64:27). Video formats with the same timing, but different 
Picture Aspect Ratios are considered different formats that can be independently supported 
and discovered. These are referred to as Dual-Aspect Ratio Timings. 


For any Dual-Aspect Ratio Video Timing, the Preferred Picture Aspect Ratio for that timing is 
indicated by the first listing of that timing in the EDID. When receiving a signal not accompanied 
by an aspect ratio indication (because no AVI InfoFrame is transmitted) a DTV shall assume that 
the aspect ratio is the Preferred Picture Aspect Ratio for the transmitted Video Timing. 


lf a Dual-Aspect Ratio DTV is receiving a Video Format Timing for which it has declared support 
for both Picture Aspect Ratios in EDID and the Source has indicated the Picture Aspect Ratio by 
including the AVI in the video stream, then the DTV shall display the Picture in the aspect ratio 
that has been indicated by the Source in the AVI. If the Source does not support transmission of 
the AVI and the Source supports both of the Dual-Aspect Ratio Video Timing Formats for a 
particular Video Timing defined by the Sink, then the Source shall provide the video to the DTV 
in the Preferred Picture Aspect Ratio. 


For a display device to simultaneously support both formats, the Source needs a way to let the 
display device know the Picture Aspect Ratio in which the video should be displayed. A DTV 
Shall list only one Picture Aspect Ratio of any Dual-Aspect Ratio Timing unless it is capable of 
receiving and decoding the AVI InfoFrame defined in Section 6. 


However, it is possible for a DTV that has no support for the AVI InfoFrame to still support both 
aspect ratios of such formats as a user programmable option. In that case, the EDID Detailed 
Timing Descriptor could be modified during operation to reflect the selected Picture Aspect 
Ratio and the change could be signaled to the Source (e.g., with Hot Plug Detect on DVI or 
HDMI). The effects on the EDID data structure are explained in Section 7.2. See Table 3 for 
Video ID Code and Aspect Ratios. 


2 2160p Video Formats with 3840 active horizontal pixels 
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Table 3 - Video Formats — Video ID Code and Aspect Ratios 
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Table 3 - Video Formats — Video ID Code and Aspect Ratios (continued) 
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50 
51 
52 
53 
54 
55 
56 
oF 
58 
59 


4:3 

720(1440)x480i 
720(1440)x480i 32:27 
720x576p 16:15 
720x576p 64:45 
720(1440)x576i 16:15 
720(1440)x5761 64:45 
720x480p 
720x480p 32:27 
720(1440)x480i 
720(1440)x480i 32:27 
1280x720p : 
1280x720p : 
1280x720p 3 


RP |e 
me |e 


61 
62 
63 


mle 
“ae 


1280x720p 23.98Hz/24Hz 64:276 : 
1280x720p 29.97Hz/30Hz 64:276 : 


Nr 
OW |e 


65 


AS 
WW 


67 


. ee 
W | W | WW 


1280x720p 59.94Hz/60Hz 64:27 


70 1280x720p 100Hz 64:27 
71 1280x720p 119.88/120Hz 64:275 
72 1920x1080p 23.98H2/24Hz 64:275 
73___| 1920x1080p 64:278 
74 1920x1080p 29.97H2/30Hz 64:27 
75___ | 1920x1080p 64:275 
76 1920x1080p 59.94Hz/60Hz 64:27 
77 1920x1080p 100Hz 64:275 
78 1920x1080p 119.88/120Hz 64:275 
79 1680x720p 23.98Hz/24Hz 64:27 64:63 

1680x720p 64.275 64:63 
81 1680x720p 29.97Hz/30Hz 64:27 64:63 
82 1680x720p 64:279 64:63 
83 1680x720p 59.94Hz/60Hz 64:278 64:63 

1680x720p 100Hz 64:278 64:63 
85 1680x720p 119.88/120Hz 64:27 64:63 

2560x1080p 23.98H2/24Hz 64:27 
88 2560x1080p 29.97H2/30Hz 64:278 

2560x1080p 64:278 11 
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Table 3 - Video Formats — Video ID Code and Aspect Ratios (continued) 


wc [Formats rettnate aot a ey 
a 0 
1 


a 
me | Re 


3840x2160p 29.97Hz/30Hz 1:1 


3840x2160p 59.94Hz/60Hz : 
4096x2160p 23.98Hz/24Hz 256:135 : 


WO WO WO 
~N ul eS) 


PlR] Re 
Pile |e 


100 4096x2160p 29.97Hz/30Hz 256:135 1:1 
101 4096x2160p 256:135 iA 
102 4096x2160p 59.94Hz/60Hz 256:135 1:1 
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103 
104 


H/HR]A 
W] WwW] Ww 
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107 3840x2160p 59.94Hz/60Hz 64:275 4:3 


1280x720p 47.95Hz/48Hz 
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108 
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OW | Re 


110 1680x720p 47.95Hz/48Hz 64:275 64:63 
111 1920x1080p 47.95Hz/48Hz 1:1 
112 1920x1080p 47.95Hz/48Hz 64:275 4:3 
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Pile] eR 
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Table 3 - Video Formats — Video ID Code and Aspect Ratios (continued) 
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4.2 Frame Rate Relationships 


Some Video Formats have a high frame rate that is an integer (2X, 4X, or 5X) multiple of the 
frame rate of a base (1X) Video Format. While receiving certain low frame rate Video Formats, 
some Sources may calculate extra interpolated frames, and output a related high frame rate 
Video Format — in order to optimize display performance. Table 4 lists the VICs of base Video 
Formats along with the VICs of their higher frame rate counterparts. 


Table 4 - Frame Rate Relationships — Base to High Frame Rate VICs 
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5 COLOR ENCODING, SAMPLING, & CONVERSION 


5.1 Default Encoding Parameters 


When present, encoding parameters specified in the AVI InfoFrame, or other interface-specific 
controls (e.g., HDMI General Control Packets), shall take precedence over any default 
parameters defined in this sub-section. 


The default Component Depth shall be 8-bits (N=8). Other elements of the default parameter 
set vary as a function of Video Format Timing type (IT or CE) and (in the case of CE Video 
Format Timings) vertical Active Line count (Vactive). 


Table 5 defines default Quantization Ranges for various colorimetries and Video Formats?. 
Methods may be provided to override these default Quantization Ranges for any Video Format 
(see Sections 6.4.3 and 7.5.6). 


Table 5 - Default Quantization Ranges 


Colorimetry 


1 The quantization range of the xvYCCgo1 and xvYCC709 colorimetries is always Limited Range, but 
values outside that range are allowed to represent an extended gamut (see IEC 61966-2-4 [5]). 


When transmitting IT Video Formats, the default color space shall be RGB using Full Range 
quantization levels. The RGB color space used for the transmission of IT Video Formats should 
be the RGB color space the Sink declares in the Basic Display Parameters and Feature Block of 
its EDID (see Sections A.2.6 and A.2.7 for further information). Most Sources default to RGB 
color space when transmitting IT Video Formats. 


3 Historically video for Consumer Electronics applications uses Limited Range due to both legacy considerations (analog TV 
overshoot/undershoot) and the prevalence of interfaces such as SDI that use embedded synchronization packets that prevent 
the use of Full Range Quantization. 
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If a Source determines that a Sink is incapable of receiving AVI InfoFrames or is incapable of 
receiving YCgCr Pixel Data, then it shall, by default, encode the CE Video Format Pixel Data in 
RGB color space using Limited Range levels. If a Sink is incapable of receiving AVI InfoFrames, 
incapable of receiving YCgCr Pixel Data, or does not receive an AVI InfoFrame, then it should, by 
default, assume CE Video Format Pixel Data is encoded in RGB color space using Limited Range 
levels and IT Video Format Pixel Data is encoded in RGB color space using Full Range levels. In 
all cases described above, the RGB color space used should be the RGB color space the Sink 
declares in the Basic Display Parameters and Feature Block of its EDID. 


If a Source determines that a Sink is capable of receiving AVI InfoFrames and is capable of 
receiving YCgCr Pixel Data, then it shall, by default, encode CE Video Format Pixel Data in a color 
space determined by the vertical Active Line count (Vactive) using Limited Range levels. By 
default, an SD Video Format shall be encoded according to SMPTE ST 170 [1] color space, an HD 
Video Format shall be encoded according to Rec. ITU-R BT.709 [7] color space, and a 2160p 
Video Format shall also be encoded according to Rec. ITU-R BT.709 [7] color space. 


5.2 Color Component Samples 


Color is communicated using a set of three components. This interface shall be capable of 
supporting RGB (red, green, and blue), with encoding parameters based on the format. 


The interface may optionally support color formats that allow sub-sampling of chroma, referred 
to as YCgCa’* or YCC in this specification. The colorimetries used by these formats include SMPTE 
ST 170, Rec. ITU-R BT.709, xvYCC, sYCC, opYCC, Y'cC'sacC'rc, Y'C’sC'r, and ICrCp. When any of 
these colorimetries are used, the chroma sampling format (4:4:4, 4:2:2, or 4:2:0) shall be 
signaled using the Y field in the AVI InfoFrame (see Section 6.4.2). 


ICrCp is signaled and transmitted equivalent to the YCgCr colorimetries. All YCC-related fields 
and flags shall apply, including, but not limited to, signaling with the Y and YQ fields of the AVI 
InfoFrame (see Section 6.4.3), the QY flag in the VCDB (see Section 7.5.6) and the Y420VDB and 
Y420CMDB (see Sections 7.5.10 and 7.5.11). 


Pixel Data with ICtCp colorimetry shall use the following component mapping: The | component 
shall be carried in the Y Color Component Sample, Cr shall be carried in the Cg Color Component 
Sample, and Cp shall be carried in the Cg Color Component Sample. 


5.2.1 RGB Conversion Matrices 
A transformation from YCgCe or ICrCp to RGB generally occurs within the DTV after it receives a 


YCsCr or ICrCp encoded Picture. A transformation between YCgCr Color Component Samples and 
RGB Color Component Samples can be accomplished by applying one of four conversion 


4 Typically, YCgCg notation is used for digital domains; and YPsPr is used for analog domains. RGB signals have the same notation 
in the digital and analog domains. 
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matrices: Rec. ITU-R BT.601 [6], Rec. ITU-R BT.709 [7], Rec. ITU-R BT.2020 [40] non-constant 
luminance, or Rec. ITU-R BT.2020 [40] constant luminance. A transformation between |ICrCp 
Color Component Samples and RGB Color Component Samples can be accomplished by 
applying one of two conversion matrices: Rec. ITU-R BT.2100 [48] constant intensity I|C7Cp color 
conversion matrix for PQ or HLG. The specific conversion matrix required depends on the 
Colorimetry and Extended Colorimetry fields in the AVI InfoFrame. The conversion matrix is 
either specified explicitly (e.g., the Colorimetry field is set to Rec. ITU-R BT.601 or Rec. ITU-R 
BT.709) or it is denoted in the subscript of the short name of the selected YCgCe colorimetry. 
For example, the Rec. ITU-R BT.601 conversion matrix applied to s¥CCéo1 or op YCCéo1 Color 
Component Samples results in RGB Color Component Samples (both positive and negative). 


5.2.2 Sample Lattice 


In order to improve color reproduction, the sample lattice for RGB, YCgCre 4:2:2, and ICrCp 4:2:2 
Pixel Data should conform to the Rec. ITU-R BT.709 [7] sampling lattice. The sample lattice for 
these Pixel Data encodings are described below for convenience: 


e R,G,B, Y, and! components are orthogonal, line- and picture-repetitive. R, G, and B 
components are co-sited with each other. 


e Cz, Cr, Cr, and Cp are orthogonal, line- and picture-repetitive co-sited with each other 
and with alternate Y or | samples (starting with the first active Y or | sample ina line). 


The sample lattice for YCgCr 4:4:4 and IC1Cp 4:4:4 Pixel Data should be the same as the sample 
lattice for RGB Pixel Data. 


5.3. Transfer Characteristic (e.g., gamma correction) 


The transfer characteristics for all supported colorimetries are shown in Table 6. The first 
column for the SDR Gamma Transfer Function applies when no Dynamic Range and Mastering 
InfoFrame is being used to specify a Transfer Function; the remaining columns apply when 
using a Dynamic Range and Mastering InfoFrame (see Section 6.9 for details on Gamma - HDR, 
PQ, and HLG Transfer Functions). In Table 6, P refers to the peak encoded luminance, and y is 
the assumed gamma value of the display. 
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Transfer Function 


Gamma - SDR 
(P = 100 cd/m2 


unless specified below) 
RGB Rec. ITU-R BT.709 [7] 
OpRGB vy = 2.19921875, 
P = 160 cd/m2 


Rec. ITU-R BT.2020 R'G'B' Rec. ITU-R BT.2020 [40] 
Table 4 


Gamma - HDR 
(P = max_display_- 
mastering luminance) 
Rec. ITU-R BT.709 [7] 
Item 1.2 


y = 2.19921875 
Rec. ITU-R BT.2020 [40] 
Table 4 


SMPTE ST 2113 P3D65 vy =2.6, 
R'G'B' P = 48 cd/m2 


SMPTE ST 2113 P3DCI vy = 2.6, 


R'G'B' P = 48 cd/m2 


SMPTE ST 170 or 
Rec. ITU-R BT.709 


Rec. ITU-R BT.709 [7] 
Item 1.2 


Rec. ITU-R BT.709 [7] 
Item 1.2 


Rec. ITU-R 
BT.2100 [48] 
Table 4 

Rec. ITU-R 
BT.2100 [48] 
Table 4 

Rec. ITU-R 
BT.2100 [48] 
Table 4 

Rec. ITU-R 
BT.2100 [48] 
Table 4 

Rec. ITU-R 
BT.2100 [48] 
Table 4 

Rec. ITU-R 
BT.2100 [48] 
Table 4 


Rec. ITU-R 
BT.2100 [48] 
Table 5 

Rec. ITU-R 
BT.2100 [48] 
Table 5 

Rec. ITU-R 
BT.2100 [48] 
Table 5 

Rec. ITU-R 
BT.2100 [48] 
Table 5 

Rec. ITU-R 
BT.2100 [48] 
Table 5 

Rec. ITU-R 
BT.2100 [48] 
Table 5 


Section 4.2 Section 4.2 
Section 4.3 Section 4.3 
Section 5.2 Section 5.2 
P = 160 cd/m2 
Rec. ITU-R BT.2020 Rec. ITU-R BT.2020 [40] 
Table 4 (CL) 


Y'cC'pcC'rc Table 4 (CL) 
Rec. ITU-R BT.2020 Rec. ITU-R BT.2020 [40] Rec. ITU-R BT.2020 [40] Rec. ITU-R Rec. ITU-R 
Table 4 (NCL) BT.2100 [43] BT.2100 [43] 


Y'C'gC'r Table 4 (NCL) 
Table 4 Table 5 
_ 


Rec. ITU-R BT.2100 IC;Cp Rec. ITU-R Rec. ITU-R 
5.4 Color Coding & Quantization 


BT.2100 [48] BT.2100 [48] 
Table 7 (PQ) Table 7 (HLG) 


Component Depth: The coding shall be N-bit, where N = 8, 10, 12, or 16 bits/component — 
except in the case of the default 640x480 Video Timing 1, where the value of N shall be 8. 


Rounding: code = Floor (X + 0.5), where X is the result of a floating point calculation. After 
rounding, code shall be limited according to the range given below. 
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Range: Limited Range R, G, B, Y, and | signals shall have (219 * 24(N - 8)) + 1 quantization 
levels. Limited Range Cz, Cr, C1, and Cp signals shall have (224 * 24(N - 8)) + 1 quantization 
levels. Full Range R, G, B, Y, |, Cs, Cr, Cr, and Cp signals shall have 2“N quantization levels. 


Levels: Limited Range R, G, B, Y, and | signals shall have black level corresponding to code 16 * 
2‘(N - 8) and peak white level corresponding to code 235 * 24(N - 8); Limited Range Cz, Cr, Cr, 
and Cp signals shall have a zero level corresponding to digital code 2“(N - 1) and range spanning 
codes 16 * 24(N - 8) to 240 * 24(N - 8). Full Range R, G, B, Y, and | signals shall have a black level 
corresponding to code O and peak white level corresponding to code (24N) - 1. Full Range Cz, 
Cr, Cr, and Cp signals shall have a zero level corresponding to digital code 2“(N - 1) and range 
spanning codes 0 to (24N)-1. 


Overshoot/Undershoot Regions: If the N-bit digital video signal is converted to an analog signal 
in the Sink, it is recommended that for RGB or Y or I, the black level (i.e., sync level and blanking 
level) be aligned with the video portion of the signal at black and white digital levels 16 * 24(N - 
8) and 235 * 24(N - 8), respectively, such that the Limited Range digital signal swing 
corresponds to the nominal analog video swing (e.g., 0 to 7OOmvV per Sections 9.4, 10.5, and 
10.6 of SMPTE ST 274 [2]). This means that zero analog level (0.0 IRE Units) should be 
associated with digital level 16 * 24(N - 8). Digital levels in an undershoot region 1 to (16 * 24(N 
- 8)) - 1 and overshoot region (235 * 24(N - 8)) + 1 to (24N) - 2 are recommended to be passed 
through the digital to analog converter; however, limited range of the analog signal should be 
aligned with the range 16 * 24(N - 8) to 235 * 24(N - 8) since it is expected that this range 
contains essential video. For the 640x480p format, it is recommended that the full O - 255 range 
be displayed for this format. 


Forbidden Values: For Limited Range R, G, B, Y, I, Cs, Cr, Cr, Cp signals, codes outside the range 
2‘(N - 8) to (255 * 24(N - 8)) - 1 are reserved and shall not be considered video. 
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6 AUXILIARY INFORMATION CARRIED FROM SOURCE TO SINK 


Various types of auxiliary data can be carried from the Source to the Sink using InfoFrames. This 
section describes the InfoFrames that have been defined so far. 


The actual mechanism for carrying these InfoFrames may vary depending on the digital 
interface being used?. 


Sources and Sinks shall not rely on the Revision Number in the CTA Extension of the Sink’s EDID 
to determine whether a Sink can accept InfoFrames. Sinks shall declare InfoFrame capability by 
including an interface related (e.g., HDMI) VSDB in their EDID CTA Extension. Sources shall only 
assume InfoFrame capability, when an appropriate (e.g., HDMI) VSDB is found. 


Note: Previous versions of CTA-861 relied on a Revision Number in the included CTA 
Extension to indicate whether the Sink could accept InfoFrames. Due to a significant 
number of DVI (not InfoFrame-capable) Sinks having the Revision Number set to 3, 
indicating support of InfoFrames, and not being capable of doing so, it is necessary to 
deprecate this requirement. 


DVI does not support the transmission of any InfoFrames, independent of CTA Extension 
version number. Sinks with a VSDB indicating support for reception of InfoFrames shall accept 
any of the InfoFrames defined here. 


The assigned type codes for InfoFrames are shown in Table 7. The first byte of the InfoFrame 
designates the type of InfoFrame while the second byte indicates the version of that particular 
InfoFrame. All future versions of a specific InfoFrame shall be backward compatible with 
previous versions. They may contain additional information, but old and new devices should be 
able to access and interpret the information previously received. 


Extended InfoFrames are distinct from InfoFrames and are described in Section 6.10. 


> Neither DVI 1.0 [4] nor OpenLDI 0.95 [8] contain a mechanism for transporting InfoFrames. These physical interfaces can be 
used to implement this standard with reduced functionality. HDMI, which is backward compatible with DVI 1.0 and contains 
mechanisms for transferring InfoFrames, digital audio, and YCgCz Pixel Data, is available and can be used to implement the full 
capabilities of CTA-861. 
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Table 7 - List of InfoFrame Type Codes 


Info Frame Type Type of InfoFrame 
Code 


The InfoFrame Length Field is contained in the third byte of each InfoFrame. This length field is 
the total number of bytes in the InfoFrame Payload. It does not include the Type, Version, or 
Length fields. In the case of the Vendor-Specific InfoFrame, the length includes the IEEE 
Registration ID, also called OUI, as well as any additional bytes defined by the vendor to be in 
the InfoFrame (see Table 8). The IEEE Company ID (CID) can be used in place of the OUI. If the 
InfoFrame Length field is not set correctly, Sinks might not be able to parse the InfoFrame 
correctly. 


6.1 Vendor-Specific InfoFrames 


The content of the Vendor-Specific InfoFrame is defined in Table 8 and Table 9. This InfoFrame 
can be used by product manufacturers or organizations that have an assigned 24-bit IEEE 
Registration Identifier to transport information not defined elsewhere. The Vendor-Specific 
Payload would be defined by the organization to which the 24-bit IEEE number refers. The 24- 
bit IEEE number is sent the least significant byte first. It is recommended that the Vendor- 
Specific Payload contain a “length field” to facilitate extensibility, but this is not required. 


Any organization or vendor that wishes to define a Vendor-Specific InfoFrame shall obtain a 
registration ID (also known as vendor ID, organizationally unique ID or company ID) from the 
IEEE Registration Authority [128]. 
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Table 8 - Vendor-Specific InfoFrame (Version 1) 


InfoFrame Type Code InfoFrame Type = 0x01 
InfoFrame Version Number Version = 0x01 


InfoFrame Length (Ly) Total number of bytes in InfoFrame Payload 
: : including IEEE Registration ID 


Data Byte 1 IEEE OUI third two hex digits 


Data Byte 2 oe a a neeistialion IEEE OUI second two hex digits 
Identifier 
Data Byte 3 IEEE OUI first two hex digits 


Data Byte 4 
Vendor-Specific Payload 


Data Byte Ly 


Table 9 - Vendor-Specific InfoFrame (Version 2) 


InfoFrame Type Code InfoFrame Type = 0x01 


InfoFrame Version Number (bits 0 — 6) and VSIF 
Change Bit (bit 7) 


InfoFrame Length (Ly) Total number of bytes in InfoFrame Payload 
: including IEEE Registration ID 


Data Byte 1 IEEE OUI third two hex digits 


Oorl Version = Ox02 


Data Byte 2 = bit ae Registration IEEE OUI second two hex digits 
Identifier 
Data Byte 3 IEEE OUI first two hex digits 


Data Byte 4 


Vendor-Specific Payload 
Data Byte Ly 


6.1.1 Multiple VSIF Handling 


The following requirements ensure the highest level of interoperability with legacy devices that 
may or may not support 1 or more VSIFs and devices supporting the use of VSIFs. 


a) Source devices transmitting one or more Vendor-Specific InfoFrames (VSIFs) shall 
transmit all such VSIFs during a single vertical blanking interval (VBI). In the case of 
interlaced formats, the VSIFs shall be transmitted immediately prior to the first of the 
two fields. It is permissible to also send the VSIF data immediately prior to the second of 
two fields. 

b) When transmitting Vendor-Specific InfoFrames, Source devices shall transmit all of them 
at least once per two Video Fields. 

c) Ifa Source device transmits Interface VSIF(s) as well as other VSIF(s), it shall transmit the 
Interface VSIF(s) last. 
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d) The information carried in one or more VSIFs transmitted in the same VBI shall apply to 
the Video Field/Frame directly following the VBI. 

e) Sink devices should apply the VSIF information from a given VSIF type to the subsequent 
Field/Frames until a change is transmitted or until a VSIF has not been received for two 
sequential Fields. 

f) InfoFrame information transmitted in non-VSIF(s) and the Interface VSIF(s) should 
supersede any contradictory information transmitted by ordinary VSIFs. 

g) If two (or more) VSIFs in the same VBI carry conflicting information and both are being 
acted upon by the Sink, the information contained within the VSIF received last should 
take precedence. 

h) Sink devices shall read the IEEE Registration Identifier of all VSIFs received in order to 
properly identify and process such VSIFs. 

i) Sink devices that support the processing of multiple VSIFs should support at least four 
(4) VSIFs that arrive as frequently as every VBI. 

j) Source devices shall not transmit identical VSIFs during a single VBI. 

e Vendors may choose to define more than one VSIF, however simultaneous use of 
multiple VSIFs with same OUI is discouraged as this wastes scarce resources in the 
Sink. 

k) Source and Sink devices should handle any changes to the contents of the VSIFs as a 

group. 

e When a Source transmits a sole VSIF, it shall be version 1 (see Table 8). 

e When aset of multiple VSIFs are transmitted and the Sink’s EDID contains an 
InfoFrame Data Block (see Section 7.5.9), the first VSIF shall be version 2 (see Table 
9) and the VSIFs that follow it shall be version 1 (see Table 8). In this case, the first 
VSIF shall indicate changes in the set of multiple VSIFs via its VSIF Change Bit®, which 
shall toggle from O-to-1 or from 1-to-0 each time the balance of the information in 
the first VSIF, or contents of any other VSIF in the set, changes. 

e When a set of multiple VSIFs are transmitted and the Sink’s EDID does not contain 
an InfoFrame Data Block, then all VSIFs (including the first) in the set of multiple 
VSIFs shall be version 1 (see Table 8). In this case, the first VSIF, in the series of VSIFs, 


6 Some Sinks have a single VSIF buffer and the ability to generate an interrupt in response to VSIF data changes. When the 
Source transmits a sole VSIF, VSIF interrupts can be interpreted as a change in this sole VSIF and VSIF processing in the Sink is 
infrequent (i.e., only occurs when the Source changes the content of the VSIF) and reasonable. However, when a single VSIF 
buffer is required to process multiple VSIFs, interrupts occur much more often (i.e., once for each VSIF received — since each 
VSIF received is different from the VSIF received before it) and no longer correlate with changes to individual VSIF data. Instead, 
interrupts signal the arrival of the next VSIF in a set of VSIFs. Without special measures, Sink VSIF processing might otherwise 
dominate available processor bandwidth as software would be forced to check for changes in a set of VSIFs on a frame-by- 
frame basis. To prevent this interrupt-overload, designs are used which filter only the first VSIF (or actually the first few bytes 
of the first VSIF), and provide an interrupt if something changes in these bytes. It is with this in mind that a toggle bit is added — 
to make it easy for Sink software to check when data, in a set of VSIFs, has changed — since the Source will toggle the toggle bit 
in the first VSIF to trigger the interrupt. For the Source device, which is creating a set of VSIFs, it is relatively easy to toggle a bit 
when there is a change in any of the VSIFs. 
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should’ have its contents changed by at least one bit whenever the contents of any 

other VSIF, in the set of multiple VSIFs, changes. 
e The Source shall transmit the VSIFs in the same order until any of the VSIFs change. 

I) Sink devices that support additional VSIF processing capabilities shall report those 

capabilities using an InfoFrame Data Block. Source devices shall inspect the InfoFrame 
Data Block and send the appropriate VSIF(s) per the Sink device's capabilities and 
instructions from the associated product manufacturer or organization. Repeaters 
should report their VSIF processing capability and only send those VSIF(s) consistent 
with the reported capabilities of the downstream Sink device. 


6.2 Auxiliary Video Information (AVI) InfoFrame 
This section has been removed (see Section 6.4). 

6.3 Format of Version 1 AVI InfoFrame 

This section has been removed. 

6.4 Format of Version 2, 3, & 4 AVI InfoFrames 


The Auxiliary Video Information (AVI) InfoFrame contains information that describes the Pixel 
Data carried in the next Video Field. It also contains information about the composition of the 
Picture. Also see Section 7 for EDID requirements that relate to the processing of AVI 
InfoFrames in both Source and Sinks. 


If the Source supports the transmission of the Auxiliary Video Information (AVI) and if it 
determines that the Sink is capable of receiving that information, it shall send the AVI to the 
Sink once per Video Field. The data from the AVI applies to the next full frame of video data. 


A Sink capable of receiving a Video Format with Video Identification Code greater than 7 or 
capable of receiving Dual-Aspect Ratio Timing shall be able to receive and decode the AVI 
InfoFrame described in this Section. As required in Section 7.1, a Sink declares the capability of 
receiving Video Formats generated at different Picture Aspect Ratios by listing both Video 
Formats in its EDID data structure. Simultaneous support of timings available in two different 
aspect ratios shall be indicated by listing both formats in the EDID data structure at the same 
time. 


If, for Some reason, an indication is received that conflicts with the Video Format being received 
(e.g., the Source indicates 4:3 but sends the 1920x1080i format), then the Sink shall ignore the 
conflicting information in the AVI. 


7 Otherwise, some legacy Sink devices may not know to look for (and act upon) changes in other VSIFs. 


53 


CTA-861-H 


If a Sink is capable of receiving YCgCe Pixel Data, then, as defined in Section 7.1, it is required to 
include the Version 3 CTA Extension in its EDID with at least one of the YCgCr chroma sampling 
format bits set. When a Sink’s EDID indicates that it is capable of receiving YCgCr Pixel Data the 
Sink shall be capable of receiving AVI InfoFrames. If no AVI InfoFrame is sent from the Source, 
then, as defined in Section 5.1, the Sink is required to assume that all CE Video Formats are 
encoded in RGB color space using Limited Range levels with an 8-bit Component Depth. 


The information on “Active Format Aspect Ratio,” Bar widths, overscan/underscan, non- 
uniform picture scaling, and colorimetry is information that can be used by the Sink to improve 
the picture quality. Use of this information by the Sink is optional. If this information is present 
at the Source and valid?®, and if the Sink is capable of receiving the AVI, the Source shall send the 
information. 


Note: Previous versions of CTA-861 defined a Version 1 AVI InfoFrame. Support for 
version 1 is no longer included in CTA-861. The format of the Version 2 AVI InfoFrame is 
backward compatible with Version 1. All of the fields that were contained in the Version 
1 AVI InfoFrame are also contained in the Version 2 AVI InfoFrame. Their purpose and 
use remain unchanged. The Version 3 AVI InfoFrame is backwards compatible with 
Version 2, except for cases where bits Y2 or VIC7 are set to ‘1’. A Version 3 AVI 
InfoFrame is only used when either of the most-significant bits Y2 or VIC7 are set to '1’. 


Sources shall not use AVI InfoFrame version 1. 


All fields of the Version 3 AVI InfoFrame are described in Table 10. All fields of the Version 2 AVI 
InfoFrame are the same as the Version 3, except for the Y, VIC, and Version fields. The Y and VIC 
fields of a Version 2 AVI InfoFrame do not include the most-significant bits Y2 and VIC7 shown. 
The Y2 and VIC7 bits are simply set to zero in a Version 2 AVI InfoFrame and might not be 
decoded by some Sinks. 


8 The data may not be valid if, for example, the stream was converted from an analog signal with no reliable aspect ratio or 
format information. 
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Table 10 - Auxiliary Video Information (AVI) InfoFrame Format (Versions 2 & 3) 


InfoFrame Type Code InfoFrame Type = 0x02 


Version = 0x02 or [0x03] 


pova {| yo | ao | Bt | Boo] st 
| cof mi | mo of R38 | RA TR 

E eca_ | eco | at | a | sa | 
Data Byte 4 vICo 
Data Byte 5 | Yar | yao | cna | cno | PR3_ | PR2_ | PRI 
Data Byte 6 
Data Byte 7 
Data Byte 8 
Data Byte 9 
Data Byte 13 


1 0 AO B1 Sd 
0 1 MO R3 R1 

Data Byte 3 ECO Ql SC 
Qo N1 CNO PR3 PR1 


All fields of the Version 4 AVI InfoFrame are described in Table 11. All fields of the Version 4 
AVI InfoFrame are the same as Version 3 AVI InfoFrame, except for the InfoFrame Version 
Number, Length of AVI InfoFrame, and additional Data Byte 14. 


Table 11 - Auxiliary Video Information (AVI) InfoFrame Format (Version 4) 


InfoFrame Type Code InfoFrame Type = 0x02 


Version = 0x04 


YQ1 
Data Byte 7 
Data Byte 8 
Data Byte 9 


Data Byte 10 
Data Byte 14 


Sinks that support AVI InfoFrames shall include support for AVI InfoFrame Version 2. 


Sinks implicitly advertise support for Version 3 AVI InfoFrames by declaring support for VIC2=128 
or Y=7 or both. 


Sinks implicitly advertise support for both Versions 3 and 4 AVI InfoFrames by declaring support 
for any standard indicated by ACE (Additional Colorimetry Extension listed in Table 17) in their 
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Colorimetry Data Block (Table 78). Sinks that support AVI InfoFrame Version 4 shall also support 
AVI InfoFrame Version 3. 


Sources shall not send AVI InfoFrame Version 3 to Sinks that do not indicate support for AVI 
InfoFrame Version 3 as described above. 


Sources shall not send AVI InfoFrame Version 4 to Sinks that do not indicate support for AVI 
InfoFrame Version 4 as described above. 


When Y=7, the IDO defines the C, EC, and ACE fields. In this case the Source shall set the AVI 
InfoFrame Version field to no less than 3. AVI InfoFrame Version 3 indicates that Byte 14 is not 
transmitted, while AVI InfoFrame Version 4 indicates the presence of Byte 14. When Y<7, 
Sources shall use the following algorithm for AVI InfoFrame Version selection: 


if (C=3 and EC=7) 

Sources shall use AVI InfoFrame Version 4. 
Else if (VIC=128) 

Sources shall use AVI InfoFrame Version 3. 
Else 

Sources shall use AVI InfoFrame Version 2. 


End if 
6.4.1 Video Format, Picture Aspect Ratio and Pixel Repetition 


Bits O through 7 of Data Byte 4 contain a Video Identification Code (VIC). In most cases, the 
Video Format can be uniquely determined from the Video Format Timing itself. However, if the 
Source is sending one of the Video Formats defined in CTA-861, then it shall set this field to the 
proper code. If a Video Format not listed in CTA-861 is sent, then the Video Identification Code 
shall be set to 0. If a modified? version of a Video Format listed in CTA-861 is sent (e.g., 
modified for some 3D modes or YCgCr 4:2:0), then the Video Identification Code shall be set in 
accordance with the IDO's specification. If the Sink receives VIC=0, and the IDO's specification 
defines an alternative method of identifying a CTA-861 Video Format, then that method shall 
be used to determine the VIC of the received Video Format. 


? Video timing might be modified from that given in Table 1 and Table 2, when Y=3 (Y2=0, Y1=1, 
YO=1) in Data Byte 1 (i.e., YCgCr 4:2:0), or when Y=7 (Y2=1, Y1=1, YO=1) in Data Byte 1 (i.e., IDO- 
defined), or when an overriding IDO-defined 3D mode is present (see Annex O). In the case of 
YCgCr 4:2:0, the pixel rate is reduced by half, along with the Htotal, Hactive, Hblank, Hfront, 
Hsync, and Hback timing parameters. In the case of 3D, the pixel frequency might be doubled 
and Vsync pulses skipped. 
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If no CTA-861 Video Format was identified (VIC=0), or the Video Format Timing does not match 
that of the identified CTA-861 Video Format, then the Sink shall attempt to determine the VIC 
based on the Video Format Timing itself. 


The codes associated with each Video Format are shown in Table 3. These same codes are used 
in the Short Video Descriptors used in the Version 3 CTA Extension, which is described in 
Section 7.3.3. 
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The following pseudo code illustrates how Sink devices shall interpret VIC codes sent by a 
Source: 


If VIC == O then 
Determine the VIC based on alternative methods (if any) as defined by the IDO 


If VIC == O then 
Attempt to determine the VIC based on the detected Video Format 
Timing 
End If 
End If 
If VIC == 0 then 


Video Format not documented in CTA-861 (not a “CE Video Format” or 
“640x480p”). 


Elseif VIC >= 1 and VIC <= 64 then 
7-bit VIC with bit-7 set to 0 

Elseif VIC >= 65 and VIC <= 127 then 
8-bit VIC (first set) 

Elseif VIC == 128 then 
Reserved 

Elseif VIC >= 129 and VIC <= 192 then 
Forbidden 

Elseif VIC >= 193 and VIC <= 253 then 
8-bit VIC (second set) 

Elseif VIC == 254 then 
Reserved 

Elseif VIC == 255 then 
Reserved 


End if 


Data Byte 2, bits M1 and MO, contain the Picture Aspect Ratio. When VIC=0, the AVI M field 
may be used to signal a Picture Aspect Ratio. When M=0 (M1=0, MO=0) and VIC=0, the Picture 
is considered to be formatted according to the Preferred Picture Aspect Ratio. If the AVI VIC is 
not O, then the Sink shall ignore this field and instead use the Picture Aspect Ratio entry in 
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Table 3 associated with the AVI VIC, and the Source shall set M to the matching Picture Aspect 
Ratio of the AVI VIC or to O if there is no match. 


Table 12 - AVI InfoFrame Picture Aspect Ratio Field, Data Byte 2 


Data Byte 5, bits PR2 through PRO, contain the pixel repetition field (PR). The first transmitted 
Active Pixel of an Active Line shall be unique. When PR is zero, the second through the last 
transmitted Active Pixel shall each be unique. When PR is greater than zero, Unique Active 
Pixels are transmitted less often as the Source shall repeat each Unique Active Pixel PR-times. 
Unique Active Pixels are always vertically aligned and horizontally spaced at PR+1 Active Pixel 
(clock) intervals. The values for PR are shown in Table 13. 


Table 13 - AVI InfoFrame Pixel Repetition Field, Data Byte 5 


Tera [ er [ pha [ pro [Pinel Repetition Factor 
po {[ o | 0 | 0 | _NoRepetition(i.e., pixeldatasent once) | 
po | Oo | oO | 1 | Pixel Data sent 2 times (i.e., repeated once) _| 


Eston 
| oo | 1 [  PixelDatasent10times 


= I | 
I | 
Lee I I 
I | 


A Source shall correctly set the PR field whenever it sends an AVI InfoFrame to a Sink — no 
matter what Video Timing Format is being transmitted. A list of allowable PR values for each CE 
Video Format is shown in Table 14. Note that this characteristic is independent of Picture 
Aspect Ratio. When a Source outputs a Video Timing Format with non-repeated pixels, PR shall 
be set to 0. When a Source outputs a double-clocked Video Timing Format, PR shall be set to 1. 
When a Source outputs Video Timing Formats 10 through 15, 25 through 30, or 35 through 38, 
it shall send an AVI InfoFrame indicating the specific PR being used and the Sink shall properly 
interpret it — decimating or repeating pixels depending on the signal process. 


Video Timing Formats with Video Identification Codes 10 through 15, 25 through 30, and 35 
through 38 support variable horizontal resolution. These Video Formats maintain a fixed 1440- 
or 2880-pixel Hactive and use pixel repetition to, in effect, provide different horizontal 
resolutions. 


59 


CTA-861-H 


Video formats with Video Identification Codes 10 through 13 and 25 through 28 keep Hactive 
fixed at 2880 pixels and allow PR to be varied over a 9-to-0 range thereby providing effective 
resolutions of 288, 320, 360, 411, 480, 576, 720, 960, 1440, and 2880 Unique Active Pixels per 
Video Line, respectively. In addition, gaming formats typically utilize optional left and right Bars, 
which insure that all of the pixels in a game are visible on overscanned displays and further 
reduce the number of Unique Content Pixels to 256, 284, 320, 366, 427, 512, 640, 853, 1280, 
and 2560 pixels, respectively. When Hactive is not an integer multiple of PR+1, the Source shall 
adjust the Bars on each side so that the width of the left Bar is an integer multiple of PR+1 and 
the right Bar begins with a Unique Active Pixel. Table 15 gives recommended Bar placement for 
each value of PR in the form of AVI Bar Data. 


Video formats with Video Identification Codes 14, 15, 29, and 30 allow PR to be set to 1 or O 
thereby providing effective resolutions of 720 or 1440 Unique Active Pixels per Video Line, 
respectively. 


Video formats with Video Identification Codes 35 through 38 allow PR to be set to 3, 1, or 0 
thereby providing effective resolutions of 720, 1440, or 2880 Unique Active Pixels per Video 
Line, respectively. 
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Table 14 - Valid Pixel Repeat Values for Each Video Format Timing 


AVI w/PR 
Video Description Valid Pixel Repeat Values 
Required 


(40 | 1920x10801@ 100Hz_ | NoRepetition | NO 
(46 | 1920x1080i @ 119.88/120Hz | NoRepetition | NO 
(80 | 1680x720p @25Hz_ | NoRepetition | NO 
(84 | 1680x720p @100Hz_— | NoRepetition | NO 


61 


CTA-861-H 


Table 14 - Valid Pixel Repeat Values for Each Video Format Timing (continued) 


AVI w/PR 
VIC Video Description Valid Pixel Repeat Values se 
Required 


ras] 25e0x1080p @ 23.98ne/oanz | NoRepetition ——S~SSC*N 
[a9 | 2560x1080 @ SoKz _—=—~=S~S~S~S~S (NN Repetition ——SSCSCS~dtC~‘ti SS 
30 | 2560%1080p @ 59.94/60 | NoRepetition | No 
98 | 409632160 @ 23.98H:/24Hz | NoRepetition | No 
[99 | 4096121609 @ 25Hz _—~=~S~S~*~*S~w (NN Repetition ——SSCSC~*~SC*‘“‘“i CSCS 
ti 

r 

r 

i 

: 

3 

3 

3 


[21s | 409632160p @ 1002 ——~SSSS*d CN Repetition 
[21s | 409632160 @ 119.88/1002 | No Repetition SS 


5 
6 : 
7 
3 5 : 
; 7 
, 
, 
: 
18 
19 


2 
2 
2 
2 
2 
2 
2 
2 
2 
2 
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Table 15 - Typical Gaming Format AVI InfoFrame Parameters 


Unique Active Pixel pi ae AVI - AVI AVI 
Spacing (in Video Pixels) PR ELB SRB 
Pixels Pixels 


Se 


pots tf 2721 


6.4.2 Color Component Sample Format and Colorimetry 


Data Bytes 1, 2, 3 and 14 contain bits that indicate the Color Component Sample format and 
chroma sampling, and describe colorimetry. 


Data Byte 1, bits Y2, Y1, and YO set the Color Component Sample format and chroma sampling 
format of the next Picture. The Source shall first determine if the Sink is capable of receiving 
YCgCr Pixel Data in the defined chroma sampling format prior to sending such data. See 
Sections 7.1 and 7.3.3 for a description of a Sink’s support of YCgCr chroma sampling formats. 


Table 16 - AVI InfoFrame RGB or YCgCr Field, Data Byte 1 


Topo [ol Ree deraury 
rofo[1 | veutnana 


YCgCp 4:4:4 


Data Byte 2, bits C1 and CO, are used in conjunction with Data Byte 3, EC2 through ECO, and 
Data Byte 14, ACE3 through ACEO, to override the default color spaces and explicitly indicate 
the colorimetry of the next Picture. The extended colorimetry bits, EC2, EC1, and ECO, describe 
optional colorimetry encoding that may be applicable to some implementations. 


If bits CO and C1 are zero, the colorimetry shall correspond to the default colorimetry defined in 
Section 5.1. A Source shall be prohibited from setting C=1 (C1=0, CO=1) or C=2 (C1=1, CO=0) 
when Y=0 (Y2=0, Y1=0, YO=0) in Data Byte 1. When C=3, colorimetry is indicated in bits ECO 
through EC2. When EC=7, colorimetry is indicated in bits ACEO through ACE3. The EC field shall 
be set to 0 by the Source unless C=3. The EC field shall be ignored by the Sink unless C=3. The 
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ACE field (if present) shall be set to O by the Source unless EC=7. The ACE field (if present) shall 
be ignored by the Sink unless EC=7. 


Table 17 - AVI InfoFrame Colorimetry Fields 


Additional Colorimetry 
Extension 
Ul oO Colorimetr peneee 
my Y Colorimetry 


MPTE ST 2113 [49] P3D65 

49] P3DCI 

fo 1 | SMPTE ST 170 [1] ais ST 2113 [49] P3DC 
alo Rec. ITU-R BT.709 
1 7] 


Extended 
Colorimetry 

el a Information Valid 
(colorimetry 
indicated in bits 
ECO, EC1, and EC2. 


Rec. ITU-R BT.2020 
R’G’B’ or Y'C'aC'p 
Additional 
Colorimetry 
Extension 
Information Valid 
(colorimetry 
indicated in bits 
ACEO, ACE1, ACE2, 
and ACE3. 


10 The YCC Quantization Range YQ bits shall be ignored by the Sink for these color spaces. 
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The Sink shall interpret the Y, C, EC, and ACE fields of Data Bytes 1, 2, 3, and 14 according to 
Table 18. A value of ‘X’ in the table indicates the Sink shall ignore the bit. A value of ‘D’ in the 
table indicates the Sink shall refer to the IDO’s standard. A reserved value in the table means 
the colorimetry assumed by the Sink is indeterminate. Sources shall be prohibited from setting 
reserved colorimetry. 


Table 18 - Picture Colorimetry Indicated by the RGB or YCgCr (Y), Colorimetry (C), Extended 
Colorimetry (EC) and Additional Colorimetry Extension (ACE) Field Settings 


RGB or Extended 


lori : 
YCpCr SOLOMIMeEny Colorimetry 
(from Data 
(from Data (from Data Byte 


Additional Colorimetry 
Extension 


from Data Byte 14 
( y ) Colorimetry of Next 


Transmitted Picture 


G 
Reserved 
Reserved 
Reserved 
opRGB 
Reserved 
Rec. ITU-R BT.2020 
R’G’B’ [40] 
SMPTE ST 2113 [49] P3D65 
R’G’B’ 
SMPTE ST 2113 [49] P3DCI 
R’G’B’ 
Reserved 
Reserved 


SMPTE ST 170 [1] or 
Rec. ITU-R BT.709 [7] 
SMPTE ST 170 [1] 


Rec. ITU-R BT.709 [7] 
XxVYCCe01 
XVYCC709 
SYCC¢01 
opYCCgo1 
Reserved 

Rec. ITU-R BT.2020 

Y'cC’pcC'rc [40] 
Rec. ITU-R BT.2020 
Y'C'gC'r [40] 
Reserved 
ec. ITU-R BT.2100 [48] IC;Cp 

Reserved 
Reserved 
Reserved 


>) 
OO 
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Table 18 - Picture Colorimetry Indicated by the RGB or YCgCp (Y), Colorimetry (C), Extended 
Colorimetry (EC) and Additional Colorimetry Extension (ACE) Field Settings (continued) 


RGB or Extended 
YCpCr 


Additional Colorimetry 
Extension 
(from Data Byte 14) 


Colorimetry : 
(from Data Colorimetry 


(from Data Byte 2) (from Data Byte 
Byte 1) 3) 


N a =) 

N | =) a oO 
O O O 
7 7 


Colorimetry of Next 


Transmitted Picture 


Rec. ITU-R BT.709 [ 7] 


ACE3 


“te 


Oofiafo} 1} a to}oto} x 
Otafo} a1} a to}o tad x 2 
Oofiafo} 1} 1 ftotilso| 
Oofifo} 1} a1 totila| 
Ee eee ee ee oe 

Rec. ITU-R BT.2020 
master 21s 12) €) 6) vecsculeo) | 258 

Rec. ITU-R BT.2020 
oils) 5 1s 1S ee vevcleo | 2 


Reserved 
Rec. ITU-R BT.2100 [48] 


Reserved 
Reserved 


r=) 
O 
= 

Reserved 


il 
IC;Cp Le | 
| Reserved] 
| Reserved | 
fos al ha | ne | ee ee | __Reserved | 
SMPTE ST 170 [1] or 
sla loa X X X 
Rec. ITU-R BT.709 [ 7] 
1{1}] o | 1 | x | x | x pe 
co{aja] 1 [of] x] x|{x_ ee ae 
Oo) a Ta a eo |] 0: | x. 
pofiltiaf2{1},o{o {ify x | 
pofiataf2 {1 },o{12{o] x | 
po;a}afo12 [1 f;,ofa]/1] x_ 
oe a | a ie eo [Reserved Sid 
Rec. ITU-R BT.2020 
Rec. ITU-R BT.2020 
om om ee 
ofafafafafafafrfo | ol]: ee | | 
TUp 
cae Eo ee ee ee is] | Reserved | 
Pek eae Bees soe | Reserved | 
oy | ae (ie |e | | Reserved | 
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Table 18 - Picture Colorimetry Indicated by the RGB or YCgCr (Y), Colorimetry (C), Extended 
Colorimetry (EC) and Additional Colorimetry Extension (ACE) Field Settings (continued) 


RGB or 


. E 
Colorimetry xtended Additional Colorimetry 


Extension 


YCsCr Colorimetry 
(from Data 
(from Data (from Data 


(from Data Byte 14) Colorimetry of Next 


Byte 1) Transmitted Picture 


es EEE EEE PE 
— aS eee ks i 


es Defined by IDO 
Defined 


Notes: 


1. A DTV declares it is capable of displaying Pictures encoded in sRGB color space (as defined in IEC 61996-2-1 [33]) by 
setting bit 2 in the Feature Support byte (0x18) of the Basic Display Parameters and Feature Block in its EDID. A Sink that 
declares it is not capable of displaying Pictures encoded in RGB color space declares its colorimetry via the values set in 
bytes 0x19 through 0x22 of the Basic Display Parameters and Feature Block in its EDID. See Sections A.2.6 and A.2.7 for 
further information. 


2. A DTV declares it is capable of displaying Pictures encoded in this colorimetry by setting the associated bit in Byte 3 of 
the Colorimetry Data Block in its EDID. See Section 7.5.5 for further information. 


3. The Picture colorimetry is dependent on the value of Vactive for the Video Identification Code set in the AVI InfoFrame. 
See Section 5 for further information. 


4. A DTV declares it is capable of displaying Pictures encoded in this colorimetry by setting bit 4 and/or bit 5 in Byte 3 of 
the CTA Extension Version 3 block in its EDID. See Section 7.3.3. 


5. Rec. ITU-R BT.2020 [40] colorimetry is only defined for Component Depths of 10 & 12-bits/component and shall not be 
used at 8-bits/component. 


6. In the case of 4:4:4 sampling, applying the constant luminance (Y'cC'gcC'rc) transform of Rec. ITU-R BT.2020 [40] might 
be of little benefit. 

Rec. ITU-R BT.2100 [48] colorimetry is only defined for Component Depths of 10 & 12-bits/component and shall not be 
used at 8-bits/component. If |CrCp colorimetry is used, the Source shall transmit a Dynamic Range and Mastering InfoFrame 
(see Section 6.9) and set the Transfer Function to be either 2 (PQ) or 3 (HLG), matching the encoding of the Picture. 


6.4.3 Quantization Range 


Displays conforming to CTA-861 accept both Limited and Full Range Quantization Range Pixel 
Data when receiving Pictures encoded in an RGB color space. The RGB quantization bits in Data 
Byte 3, bits Q1 and QO, allow the Source to override the default RGB Quantization Range and to 
explicitly indicate the RGB Quantization Range of the next Picture. A Source shall always 
explicitly signal the RGB Quantization Range as either Limited Range (Q=1) or Full Range (Q=2). 
The value Q=0 (Q1=0, QO=0) indicates that the Quantization Range corresponds to the default 
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RGB Quantization Range defined in Section 5.1, but the use of this value is deprecated and it 
shall not be used in new designs for Sources. 


If the Sink does not support Selectable RGB Quantization Range (QS=0 in the Video Capabilities 
Data Block, see Section 7.5.6), then the Source should send a Q value corresponding to the 
default RGB Quantization Range specified for the colorimetry transmitted (see Table 5). 


When the Source is transmitting any non-RGB colorimetry (Y is not 0), then the Q-field is 
unused and shall be set to O. The Sink shall ignore the Q field when any non-RGB colorimetry is 
received. 


Table 19 - AVI InfoFrame RGB Quantization Range Field, Data Byte 3 


RGB Quantization Range 


Co, Default (depends on Video Format) 
Limited Range 


(ome 
fo 
fa fo frutrange 
Reserved 


Displays conforming to CTA-861 may accept both Limited and Full Range Quantization Range 
Pixel Data when receiving Pictures encoded in an YCC color space. The YCC quantization bits in 
Data Byte 5, bits YQ1 and YQO, allow the Source to override the default YCC Quantization Range 
and to explicitly indicate the YCC Quantization Range of the next Picture. Table 20 illustrates the 
meaning assigned to these YCC Quantization Range bits YQ1 and YQO in Data Byte 5. A Source 
Shall always explicitly signal the YCC Quantization Range as either Limited Range (YQ=0) or Full 
Range (YQ=1). 


If the Sink does not support Selectable YCC Quantization Range (QY=0 in the Video Capabilities 
Data Block, see Section 7.5.6), then the Source should send a YQ value corresponding to the 
default YCC Quantization Range specified for the colorimetry transmitted (see Table 5). 


When the Source is transmitting any RGB colorimetry (Y is 0), the YQ field is unused and shall be 
set to 0. The Sink shall ignore the YQ field when any RGB colorimetry is received. 


Table 20 - AVI Info Frame YCC Quantization Range Field, Data Byte 5 


YQl YQo YCC Quantization Range 
Y=YCbCr Y=RGB 
ae a ae Limited Range Required Setting 


0 | 1 | FullRange [Reserved 
a [0 | Reserves [Reserved 
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6.4.4 Active Format and Bar Data 


Data Bytes 1, 2 and 6 through 13 contain bits that indicate the active format and/or Bar Data 
information. If the Bar Data and the active format information do not agree, then the Bar Data 


shall take precedence. 


Data Byte 1, bit AO, indicates whether Active Format Data is present in Data Byte 2 bits R3 
through RO. A Source device shall set AO=1 when any of the AFD bits are set. 


Data Byte 1, bits B1 and BO, indicate the presence and type of Bar Data transmitted in Data 
Bytes 6 through 13. The contents of Data Bytes 6 through 13 are described later in this Section. 
The presence of both vertical and horizontal Bar Data is not standardized. 


Table 21 - AVI InfoFrame Active Format Information and Bar Data Present Fields, Data Byte 1 


ae Active Format Information Present eR BO Bar Data Present 
ca No Active Format Information ee ee Bar Data not present 
7 Active Format (R3...RO) Information Eases Vert. Bar Info present 


present 
Pan eos | Horiz. Bar Info present 
Vert. and Horiz. Bar Info present 


Data Byte 2, bits R3 through RO, may be used to communicate common “Active Format” aspect 
ratio information from a Source to a display device. Table 23 illustrates the terminology and 
gives examples of common aspect ratio information. It illustrates some of the possibilities given 
three standard aspect ratios (4:3, 16:9, and 64:27) within the Picture (i.e., CTA-CEB16 Total 
Image). For the “greater than 16:9” case, an example aspect ratio of 64:27 was chosen. 


Table 22 - AVI InfoFrame Active Portion Aspect Ratio Field, Data Byte 2 


Tre [m2 | [wo [nave rerton Apa ato 
a fo fe [o [sine sr nawre nsec Ratio 
fa fo fe [a [aatcenen 
= 


fo a: 20. 16:9 (Center) 
a fo [x fa |i conten 
Varies. See Annex H. 


“Active Format” codes shall be transmitted when received with content. Originating devices 
supplying such codes may provide codes in accordance with the Active Format Description™ 


11 Note that the use of the word “active” in the “Active Format Description” differs from how it is used in other places of this 
standard and documents referenced by this standard. The word, “active” usually refers to all Active Pixels. In this case of AFD, 
the word, “active” refers only to the area containing Content Pixels and its format relative to areas potentially containing Bar 


Pixels. 
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(AFD) in SMPTE ST 2016-1 [35] and Annex B of ETSI TS 101 154 [107]. All active format codes 


defined in [35] and [107] are reproduced in informative Annex H. 


Table 23 - Common Active Formats 


active_format Description 
4:3 Total Images 16:9 Total Images 64:27 Total Images 


‘1000’ | | *s 
/ \ 

~/ VN 

o w 
\ 7 


4:3 full frame image 16:9 full frame image 64:27 full frame image 


- | i | 


4:3 full frame image 4:3 pillarbox image 4:3 pillarbox image 


- eri ee | 


16:9 letterbox image 16:9 full frame image 16:9 pillarbox image 
- oe | 
14:9 letterbox image 14:9 pillarbox image 14:9 pillarbox image 
7 ces 


“>16:9” letterbox image “>16:9” letterbox image “>16:9” full frame image 


See CTA-CEB16-B [106] for more information about AFD processing. 


Data Bytes 6 through 13 provide Bar Data encoded according to the pixel and line numbering 
scheme of CTA-861 as shown in Table 25, which is not compatible with specifications such as 
SMPTE ST 2016-1. 


Line counts used to describe a Coded Frame typically conform to SMPTE ST 2016-1 [35], Table 
2, which is informatively reproduced in Table 24. 
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Table 24 - Video Format Information (Informative) 


Li 2 
Caued Coded Lines 


Pixels? 


Coding Range 
Pixels x lines 


Applicable Standard 


Field 1 Field 2 


720 x 480 286 -5253 
720 x 480 7 
720x576 336 — 623 
720x576 7 
1280 x 720 = 


480 Interlaced SMPTE ST 125 [102] 


SMPTE ST 293 [100] 

Rec. ITU-R BT.656 [114] 
Rec. ITU-R BT.1358 [116] 
SMPTE ST 296 [101] 


480 Progressive 


576 Interlaced 


576 Progressive 


720 Progressive 


1080 Interlaced SMPTE ST 274 [2] 


SMPTE ST 274 [2] 


1920 x 1080 584 — 1123 
1920 x 1080 . 


1080 Progressive 42-1121 


1. SMPTE specifications number Coded Pixels 0-719, while CTA-861 numbers Hactive pixels 1-720. 
2. SMPTE Coded Line numbering scheme is timing-dependent, while CTA-861 Picture Line numbering scheme is not. 


3. CTA-861 and SMPTE ST 2016-1 480i Vactive centers are different. CTA-861's Vactive (22-261/285-524) follows archived 
SMPTE RP 187-1995 recommended practice, while SMPTE ST 2016-1's Vactive (23-262/286-525) is shifted down one line and 
follows current SMPTE RP 202-2008 [132] recommended practice. See SMPTE RP 202-2008 [132] Table 1, Note 2 and Section 
6.1 for further details. 


The equivalent pixel and line numbering scheme of CTA-861 is shown in Table 25. 


Table 25 - CTA-861 Picture Pixel & Line Numbers 


Picture Picture Line Number 


Coding Range ; 
Pixel 


Pixels x lines 


6,7 


480 Interlaced 


720 x 480 


Number 


Field 1 


Odd 1-479 


Field 2 


Even 2 — 480 


2,3 


480 Progressive 


720 x 480 


21,22 


576 Interlaced 


720x576 


Odd 1-575 


Even2—5/76 


17,18 


576 Progressive 


720x576 


4,19, 60-62, 
108-109 


720 Progressive 


1280 x 720 


5, 20 


1080 Interlaced 


1920 x 1080 


Odd 1- 1079 


Even 2 — 1080 


16, 32-34, 
111-112 


1080 Progressive 


1920 x 1080 


79-85, 110 


720 Progressive 


1680 x 720 


86-92, 113 


1080 Progressive 


2560 x 1080 


93-97,103-107, 
114, 116-120 


2160 Progressive 


3840 x 2160 


98-102, 115, 
218-219 


2160 Progressive 


4096 x 2160 


121-127, 193 


2160 Progressive 


5120 x 2160 


194-201 


4320 Progressive 


7680 x 4320 


202-217 


4320 Progressive 


10240 x 4320 
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Note that the pixel and line numbering schemes used to encode AFD Bar Data for program 
material conforming to SMPTE ST 2016-1 are incompatible with those specified in CTA-861. 
With respect to pixel numbering, SMPTE ST 2016-1 begins with zero, while CTA-861 begins with 
one. With respect to line numbering, SMPTE ST 2016-1 and CTA-861 timing-based line 
numbering schemes have been harmonized. However, where SMPTE ST 2016-1 uses timing- 
based line-numbering for encoding its AFD Bar Data, CTA-861 uses a separate Picture-based 
line-numbering scheme to encode its InfoFrame AFD Bar Data. Timing-based line numbering 
begins with one and at a prescribed line in the blanking interval 1-Ln lines relative to the leading 
line of Vsync. CTA-861’s Picture-based line-numbering also begins with one, but always begins 
at the leading line of Vactive (i.e., the topmost line of the Picture). 


Sources that receive Bar Data from external media (e.g., media carrying Bar Data in accordance 
with SMPTE ST 2016-1) and output it to Sink via AVI InfoFrame Bar Data, should convert the Bar 
Data according to CTA-861 standard line number and pixel number conventions (given below) 
prior to outputting. The equation for converting SMPTE ST 2016-1 Coded Pixel numbers (Psmpte) 
to equivalent CTA-861 Picture Pixel numbers (Pcta) is shown in Table 26. The equations for 
converting interlaced and progressive format SMPTE ST 2016-1 Coded Line numbers (Lsupte) to 
equivalent CTA-861 Picture Line numbers (Leta) are shown in Table 27 and Table 28, 
respectively. The equations in Table 26, Table 27, and Table 28 only apply when a Bar is 
present. CTA-861 utilizes special values (given below) when a Bar is omitted. The variables Ln, 
Vsync, Vback, Vfront, Vactive, in the equations come from Table 1 and Table 2 of CTA-861. 


Table 26 - Bar Data Pixel Number Normalization Equation 


| Format SMPTE ST 2016-1 Coded Pixel Number to CTA-861 Picture Pixel Number Conversion Equation 


All formats Pcta = Psmptet+1 


Table 27 - Interlaced Bar Data Line Number Normalization Equations 


SMPTE ST 2016-1 Coded Line Number to CTA-861 Picture Line Number Conversion Equations 
Field 1 Field 2 
Lsmpte <= [Ln + (Vtotal/2)] Lsmete > [Ln + (Vtotai/2)] 


480 Interlaced? Leta = 2*[Lsmpte-Ln-Vsync-Vback]-1 Leta = 2*[Lsmpte-Ln-Véront -2*(VsynctVback)-(Vactive/2)-1] 
Other Interlaced Leta = 2*[Lsmpte-Ln-Vsync-Vback+1]-1 Leta = 2*[Lsmpte-Ln-Véront -2* (Wsynct+Vback)-(Vactive/2) ] 


1. The 480 interlaced format is a special case, where the line number conversion equations are slightly modified due to the fact 
that SMPTE ST 2016-1 Vactive is offset relative to CTA-861 Vactive by one line (e.g., the bottom-most line in SMPTE ST 2016-1 
Vactive ends on timing line number 525, while in CTA-861, it ends one line earlier on timing line number 524). All of the other 
interlaced Video Timings align perfectly. 


Table 28 - Progressive Bar Data Line Number Normalization Equation 


| Format SMPTE ST 2016-1 Coded Line Number to CTA-861 Picture Line Number Conversion Equation 


All Progressive Lota = Lsmpte-Ln-Vsync-Vback+1 
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The general procedure for converting a SMPTE ST 2016-1 Coded Pixel number 
(pixel number _end_of_left_bar or pixel_ number_start_of_right_bar) to an equivalent CTA-861 
Picture Pixel number (ELB or SRB) and setting the CTA-861 vertical Bar Data bit (BO) is: 


1) 


2) 


3) 


Determine if a left vertical Bar is present by inspecting the SMPTE ST 2016-1 
left_bar_flag value. If the left vertical Bar is present, then use the equation in Table 26 
(i.e., simply add one) to calculate ELB. If the left vertical Bar is not present, then use the 
special value zero for ELB. 

Determine if a right vertical Bar is present by inspecting the SMPTE ST 2016-1 
right_bar_flag value. If the right vertical Bar is present, then use the equation in Table 
26 (i.e., simply add one) to calculate SRB. If the right vertical Bar is not present, then use 
the special value (Hactive+1) for SRB. 

If either vertical Bar is present, set BO bit to one. Otherwise, if neither vertical Bar is 
present, set BO bit to zero. 


The general procedure for converting a SMPTE ST 2016-1 Coded Line number 
(line_number_end_of_top_bar or line_number_start_of_bottom_bar) to a CTA-861 Picture 
Line number (ETB or SBB) and setting the CTA-861 horizontal Bar Data bit (B1) is: 


1) 


2) 


3) 


4) 


Determine if top horizontal Bar is present by inspecting the SMPTE ST 2016-1 
top_bar_flag value. If the top horizontal Bar is not present, then use the special value 
zero for ETB. If the top horizontal Bar is present and the Video Format is progressive, 
then use the equation in Table 28 to calculate ETB. Otherwise, use one of the four 
equations as described in step 3 below to calculate ETB. 

Determine if bottom horizontal Bar is present by inspecting the SMPTE ST 2016-1 
bottom_bar_flag value. If the bottom horizontal Bar is not present, then use the special 
value (Vactive+1) for SBB. If the bottom horizontal Bar is present and the Video Format 
is progressive, then use the equation in Table 28 to calculate SBB. Otherwise, use one of 
the four equations as described step 3 below to calculate SBB. 

If a horizontal Bar is present and the Video Format is interlaced, then use one of the 
four equations in Table 27 as follows: 

a) Determine if the SMPTE ST 2016-1 line number is in the first field by comparing 
the number with the value [Ln + (Vtotal/2)]. If the SMPTE ST 2016-1 number is 
less than or equal to the value [Ln + (Vtotal/2)], then use one of the equations 
from the “Field 1” column of Table 27. Otherwise, use one of the equations from 
the “Field 2” column of Table 27. 

b) Ifthe incoming Video Format is 480i, then use the appropriate equation from the 
“480 Interlaced” row ofTable 27. Otherwise, use the appropriate equation from 
the “Other Interlaced” row of Table 27. 

If either horizontal Bar is present, set B1 bit to one. Otherwise, if neither horizontal Bar 
is present, set B1 bit to zero. 


Example Bar Data conversions are shown in Annex M. 


Data Bytes 6 through 13 contain the location data for Bars. These 8 bytes are present in the AVI 
whether or not they contain the Bar Data. For the purposes of the Line Number and the Pixel 
Number, the pixel in the upper left hand corner of the Picture is considered to be in row 1, 
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column 1. Lines and pixels are numbered consecutively as they would appear on a display.” All 
of the values are unsigned integers. 


a) Line Number of End of Top Bar (ETB) — An unsigned integer value representing the last line 
of a horizontal letterbox Bar area at the top of the Picture. Zero means no horizontal Bar is 
present at the top of the Picture. 


b) Line Number of Start of Bottom Bar (SBB) — An unsigned integer value representing the 
first line of a horizontal letterbox Bar area at the bottom of the Picture. If greater than the 
Maximum Vertical Active Lines of the known format, no horizontal Bar is present at the 
bottom of the Picture. 


c) Pixel Number of End of Left Bar (ELB) — An unsigned integer value representing the last 
horizontal pixel of a vertical pillar-Bar area at the left side of the Picture. Zero means no 
vertical Bar is present on the left of the Picture. 


d 


—* 


Pixel Number of Start of Right Bar (SRB) — An unsigned integer value representing the first 
horizontal pixel of a vertical pillar-Bar area at the right side of the Picture. If greater than the 
Maximum Horizontal Pixels of the known format, no vertical Bar is present on the right side 

of the Picture. 


6.4.5 Overscan/Underscan, Scaling and Picture Content 


Data Byte 1 contains bits that describe overscan/underscan (e.g., computer graphics or video). 
Bits S1 and SO (Table 29) contain information that defines the Picture composition of the next 
Video Field. A Source shall set S=1 (S1=0, SO=1) or S=2 (S1=1, SO=0) if it is confident of the 
accuracy of those values. Otherwise, it shall set S=O (no data). The Source shall follow these 
rules for setting S even in the absence of an indication that the Sink responds to the value of S. 


A Sink should adjust its scan based on the value of S. A Sink would overscan if it received S=1, 
and underscan if it received S=2. If it receives S=0, then it should overscan for a CE Video 
Format and underscan for an IT Video Format. A Sink should indicate its overscan/underscan 
behavior using a Video Capabilities Data Block (see Section 7.5.6). 


Table 29 - AVI InfoFrame Scan Information Field, Data Byte 1 


| S1_| So_|Scaninformation 
PO | 0 [NoData 


1 {Composed for an overscanned display, where some Active 
Pixels and lines at the edges are not displayed. 


1 Composed for an underscanned display, where all Active 
Pixels & lines are displayed, with or without a border. 


12 In this context, line numbers are not the same as the line numbers used in timing diagrams. 
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Data Byte 3 contains the SC field as shown in Table 30. 
Table 30 - AVI InfoFrame Scaling Fields, Data Byte 3 


- | o | Non-Uniform Picture 
UO} O : 
”| on” | Scaling 
No Known non- 
uniform Scaling 
1 Picture has been 
scaled horizontally 


1 Picture has been 
scaled vertically 
Picture has been 

1 1 scaled horizontally 
and vertically 


Bits SC1 and SCO provide information on whether the Picture has been scaled in a non-uniform 
way (i.e., unequal along horizontal and vertical dimensions) prior to transmission to the Sink. 
The Non-uniform Picture Scaling bits shall be set if the Source scales the Picture or has 
determined that scaling has been performed in a specific direction. If the Picture has been 
stretched or shrunk in a uniform way (i.e., equally along both dimensions), then the bits should 
not be set. 


The IT content bit in Data Byte 3 (ITC) indicates when Picture content is directly composed 
according to common IT practices or derived from a specific type of IT content. When the IT 
content bit of Data Byte 3 is set to 1 (ITC = 1), the content field (CNO, CN1) of Data Byte 5 is 
valid and downstream processors should process Pixel Data according to the definitions given in 
Table 31. When the IT content bit of Data Byte 3 is false (ITC = 0), the content field (CNO, CN1) 
of Data Byte 5 shall be ignored by the Sink and shall be set to O by the Source. The IT content bit 
is about the Picture content and should not be confused with IT vs CE video timings. The IT 
content bit can be used with both video timings. 


Table 31 illustrates the meaning of Data Byte 5 Content Type bits CN1 and CNO. These bits 
should be used to signal delivery of IT content that is either classified as Graphics, Photo, 
Cinema, or Game. 


Table 31 - AVI Info Frame IT Contents Type, Data Bytes 3 and 5 


IT content IT Content Type 
To | Nodata 
IT content 


CN bits valid) 


po | OL 
ee 
(DataByteS | | 1 | 0 | Cinema 


Game 


The Graphics type is indicated by the Source to flag content composed according to common IT 
practice (i.e., without regard to Nyquist criterion) and is unsuitable for analog reconstruction or 
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filtering. In IT applications (e.g., involving bit mapped text), each pixel in the Source’s frame 
buffer is most clearly displayed if it is directly mapped to a light-emitting pixel on the display 
device — such that adjacent pixels are completely independent and do not interact. When the 
IT content bit is set to 1 and the Graphics type is indicated, downstream processors should pass 
Pixel Data unfiltered and without analog reconstruction. 


The Photo type is indicated by the Source (which might be a digital still camera, DVD player or 
other device) to flag content derived from digital still pictures. When the IT content bit is set to 
1 and the Photo type is indicated, the Sink is expected to “pass-through” still pictures with 
minimal scaling and picture enhancement in order to avoid undesirable artifacts. The Photo 
type should not be associated with device type. For example, digital still cameras may support 
delivery of video. 


The Cinema type is indicated by the Source to flag content derived from cinema material. Audio 
may be processed through an audio video amplifier (AV Amp) or Digital Television. When the IT 
content bit is set to 1 and the Cinema type is indicated, the Sink should “pass-through” cinema 
content with minimal scaling and picture enhancement in order to avoid undesirable artifacts. 
The Cinema type should not be associated with device type. For example, DVD players are 
capable of supplying various content types such as TV programs. 


The Game type is indicated by the Source to flag content derived from game machine material. 
When the IT content bit is set to 1 and the Game type is indicated, the Sink should “pass- 
through” game content with minimal scaling and picture enhancement in order to avoid 
undesirable artifacts. Audio and video latency should also be minimized. The Game type should 
not be associated with device type. For example, game machines are capable of supplying 
various content types such as DVD movies. 
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6.5 Source Product Description (SPD) InfoFrame 


The Source Product Description (SPD) InfoFrame communicates the name and product type of 
the Source. This allows the user to see which device is being selected when changing inputs on 
the Sink. 


Including an appropriate VSDB in the Sink’s EDID data structure indicates support of the SPD 
InfoFrame in the Sink. The transmission of this InfoFrame is optional for the Source. The use of 
the information by the Sink is also optional. It shall not be sent more than once per Video 
Frame. If used, it is recommended that it be sent once every second. 


The format of the Source Product Description InfoFrame is shown in Table 32. 


Table 32 - Source Product Description InfoFrame Format 


InfoFrame Type Code InfoFrame Type = 0x03 


InfoFrame Version Number Version = 0x01 
Length of Source Product Description 
InfoFrame 
Data Byte 1 
Data Byte 2 
Data Byte 3 
Data Byte 4 
Data Byte 5 
Data Byte 6 
Data Byte 7 
Data Byte 8 
Data Byte 9 
Data Byte 10 
Data Byte 11 
Data Byte 12 
Data Byte 13 
Data Byte 14 
Data Byte 15 
Data Byte 16 
Data Byte 17 
Data Byte 18 
Data Byte 19 
Data Byte 20 
Data Byte 21 
Data Byte 22 
Data Byte 23 
Data Byte 24 
Data Byte 25 


Length of Source Product Description InfoFrame = 25 


Vendor Name Character 1 VN1 (7bit ASCII code) 
Vendor Name Character 2 VN2 
Vendor Name Character 3 VN3 
Vendor Name Character 4 VN4 
Vendor Name Character5 VN5 
Vendor Name Character 6 VN6 
Vendor Name Character 7 VN7 
Vendor Name Character 8 VN8 

Product Description Character 1 PD1 (7-bit ASCII code) 
Product Description Character 2 PD2 
Product Description Character 3 PD3 
Product Description Character 4 PD4 
Product Description Character 5 PD5 
Product Description Character 6 PD6 
Product Description Character 7 PD7 
Product Description Character 8 PD8 
Product Description Character 9 PD9 

Product Description Character 10 PD10 
Product Description Character 11 PD11 
Product Description Character 12 PD12 
Product Description Character 13 PD13 
Product Description Character 14 PD14 
Product Description Character 15 PD15 
Product Description Character 16 PD16 
Source Information 


The Vendor Name consists of eight 7-bit ASCII characters. The name should be left justified (i.e., 
first character in Data Byte 1) and all unused characters should be Null (i.e., 0x00). The Vendor 
Name is intended to be the name of the company whose name appears on the product. The 
Product Description (contained in Data Bytes 9-24) consists of sixteen 7-bit ASCII characters. 
This code is meant to be the model number of the product and may contain a short description 
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also (e.g., CES24DVD Player). Data Byte 25 consists of a code that classifies the Source. Codes 
for the most common types of Sources are shown in Table 33. 


Table 33 - Source Product Description InfoFrame Data Byte 25 


Source Information 
unknown 
Digital STB 
DVD player 
D-VHS 


HDD Videorecorder 


DVC 
DSC 
Video CD 
Game 
PC general 
Blu-Ray Disc (BD) 
Super Audio CD 


HD DVD 


PMP 


Reserved 


6.6 Audio InfoFrame 


The Audio InfoFrame contains information that allows for the format of the digital audio 
streams to be identified more quickly via out-of-band information and, for multi-channel 
Uncompressed Audio (which does not otherwise give such information), provides channel 
allocation information for the Sink’s speakers. The Audio InfoFrame format is shown in Table 
34. 


If the Sink supports any digital audio, it shall be capable of receiving the Audio InfoFrame and 
also capable of interpreting the audio identification information in Data Bytes 1-3. Support for 
digital audio other than Basic Audio is indicated in the Version 3 (or higher) CTA Extension (see 
Section 7.3.3). 


If the Sink supports multi-channel (i.e., more than 2 channels) digital audio and has included 
speaker placement information in EDID (see Section 7.3.3), it shall be able to interpret the 
speaker channel assignment information and down-mix information in Data Bytes 4 & 5. 
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If the Source supports the transmission of the Audio InfoFrame and if it determines that the 
Sink is capable of receiving the Audio InfoFrame (i.e., the Sink has included CTA Extension 
Version 3 in EDID) and digital audio, then the Audio InfoFrame, with Data Bytes 1 through 3 set 
correctly, shall be sent once per Video Field while digital audio is being sent across the 
interface. The data applies to the audio associated with the next full frame of video data. 


If the Source is sending multi-channel Uncompressed Audio, then it shall also send valid speaker 
channel allocation information and down-mix information in Data Bytes 4 & 5 of this InfoFrame. 


Table 34 - Audio InfoFrame Format When Data Byte 4 is 0x00 to 0x31 


InfoFrame Type 
Code 
InfoFrame 
Version Number 
Length of Audio 
InfoFrame 


InfoFrame Type = 0x04 


Version = Ox01 


Length of Audio InfoFrame = 10 


Data Byte 1 


CTO 


F13=0 


CC2 


CC1 


CCO 


Data Byte 2 


SF2 


SF1 


SFO 


SS1 


SSO 


Data Byte 3 


CXT4 


CXT3 


CXT2 


CXT1 


CXTO 


Data Byte 4 


CA4 


CA3 


CA2 


CA1 


CAO 


Data Byte 5 


LSV1 


LSVO 


F52=0 


LFEPBL1 


LFEPBLO 


Data Byte 6 


F64=0 


F63=0 


F62=0 


F61=0 


F60=0 


Data Byte 7 


F74=0 


F73=0 


F72=0 


F71=0 


F70=0 


Data Byte 8 


F84=0 


F83=0 


F82=0 


F81=0 


F80=0 


Data Byte 9 


F94=0 


F93=0 


F92=0 


F91=0 


F90=0 


Data Byte 10 


F104=0 
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Table 35 - Audio InfoFrame Format When Data Byte 4 is OxFE 


InfoFrame Type 
Code 
InfoFrame 
Version Number 
Length of Audio 
InfoFrame 
Data Byte 1 CT3 CT2 CT1 F13=0 CC1 CCO 
Data Byte 2 F27=0 F26=0 F25=0 SF1 SS1 SSO 
Data Byte 3 F37=0 F36=0 F35=0 CXT3 CXT1 CXTO 
Data Byte 4 1 1 1 1 1 0 
Data Byte 5 DM_INH LSV3 LSV2 LSVO LFEPBL1 LFEPBLO 
Data Byte 6 FLw/ FRw F66=013 FLc/ FRc BL/BR LFE1 FL/FR 
ie SiL/ SiR |  TpBC LS/RS Tpc sie 
TpBL/ 
TpBR 
Data Byte 9 F97=0 F96=0 F95=0 F93=0 F91=0 F90=0 
Data Byte 10 F107=0 F106=0 F105=0 F103=0 F101=0 F100=0 


InfoFrame Type = 0x04 


Version = Ox01 


Length of Audio InfoFrame = 10 


Data Byte 7 


Data Byte 8 F87=0 F86=0 F85=0 F83=0"4 BtFC 


Table 36 - Audio InfoFrame Format When Data Byte 4 is OxFF 


nfoFrame Type 
Code 
InfoFrame 
Version Number 
Length of Audio 
InfoFrame 
Data Byte 1 F13=0 CC1 CCO 
Data Byte 2 SF1 SS1 SSO 
Data Byte 3 CXT3 CXT1 CXTO 
Data Byte 4 1 1 1 
Data Byte 5 LSVO LFEPBL1 LFEPBLO 
Data Byte 6 CIDO3 CIDO1 CIDOO 
Data Byte 7 CID11 CIDO9 CIDO8 
Data Byte 8 CID19 CID17 CID16 
Data Byte 9 CID27 CID25 CID24 
Data Byte 10 F103=0 F101=0 F100=0 


InfoFrame Type = 0x04 


Version = Ox01 


Length of Audio InfoFrame = 10 


13 Use of F66 for RLC/RRC has been deprecated. Sources shall direct audio intended for these channels to BL/BR, which are 
logically the same speaker positions. Legacy Sources shall not set both RLC/RRC and BL/BR and shall not transmit data in both 
pairs of channels simultaneously. Legacy Sinks shall support reception of both RLC/RRC and BL/BR data; if data is sent 
simultaneously to both pairs of channels, Sinks shall ignore the data in RLC/RRC. Future use of F66 for other speaker positions is 
reserved. 


14 Use of F83 for TpLS/TpRS has been deprecated. Future use of F83 for other speaker positions is reserved. 


80 


CTA-861-H 


6.6.1 Audio Identification Information 


The information in Data Bytes 1-3 may be useful in identifying the audio format, audio channel 
count, audio sampling frequency, and number of bits per audio sample. If the DTV and the 
Source support more than “Basic Audio,” as defined by the physical/link specification, then this 
information shall be sent and shall accurately identify the stream while digital audio is being 
sent. If the Source only supports Basic Audio, it is not required to send this information, but it is 
recommended. In most cases, it is possible to identify the audio by parsing the actual audio 
stream (e.g., as specified in IEC 60958-3 [12]). In cases where the audio information in the 
Audio InfoFrame does not agree with the actual audio stream being received, the conflicting 
information in the Audio InfoFrame shall be ignored. 


Note: HDMI requires the CT, SS, and SF fields to be set to 0 (“Refer to Stream Header’) 
when these items are indicated elsewhere. By extension the CXT field is also required to 
be set to 0. 


Data Byte 1 bits CT3, CT2, CT1, and CTO, when coded, define the audio format type of the audio 
stream. These bits may be set according to Table 37. A Sink capable of receiving digital audio 
shall determine the audio format by parsing the audio stream header when CT=0 (CT3=0, 
CT2=0, CT1=0, CTO=0). Audio format types shall be defined by the CXT field in Data Byte 3 when 
CT=15 (CT3=1, CT2=1, CT1=1, CTO=1). 


Data Byte 1, bits CC2, CC1, and CCO, when coded, indicate the audio channel count carried 
transmitted in the audio stream. These bits may be set according to Table 37. When CC=0 
(CC2=0, CC1=0, CCO=0), channel count may be determined either by examining Data Bytes 4 
and 6 to 9 (in the case of L-PCM audio or DSD audio) or from information in the bitstream (in 
the case of compressed audio). In some cases (e.g., with Object Based Audio, or compressed 
streams containing multiple channel layouts) the channel count of the rendered audio is 
determined by the Sink device. 
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Table 37 - Audio InfoFrame Data Byte 1 


wf [pore [ese pa Audio Coding Audio Stream Encoding Audio Stream c;c;c Audio Channel 
TT} T | TT Tbe Standard Transport C;i|c!ic a 
3/;2/;1/0 YP Standard 2/110 
ofoolo Refer to Stream Header le Bernas 
Header 


pofo}iay tem | ite o958-3(12} fF POLO] A] 2channels 


1 AC-3 eee nr eek [11], IEC 61937-3 [14] 1 3 channels 
excluding Annex E 
5 channels 


1 
ofila}o} aacic | iso/iec144g96-3 [25] | 1ec61937-6(17] | | 1 | 1 | 0]  7channels 
ofija}ayt ors |__ersits102114[36] | _1ec61937-5{16) | Li] 1] 1} channels 
ijolofo} atrac_ | tece1909[13) | 1c 61937-7 (18) 
p1folo}|i] OneBitaudio | ISO/IEC 14496-3[25], subpart 10 


1 1 Enhanced ac-3 | “TSCA/S2BI11L with | tee 61937-3 14] 
Annex E 
DTS-HD ETSI TS 102 114 [36] 
ifofa)a DTS-UHD ETSI TS 103 491 [37] bee a 
f1]/1]}0]0O] = MAT | DVD Forum MLP [27] IEC 61937-9 [20] 
EE Ano a= = ist — | ISO/IEC 14496-3 [25] subpart 10 


WMA Pro Decoder 
fafa fol ware | WHAP Decoder Tec eiss7 89 


Refer to Audio Coding Extension Type (CXT) field in Data Byte 3 


BORE 
1 MP3 ISOMEC 11172-3 [23] IEC 61937-4 [15] 1 
Layer 3 


ofijo|a}  mpec2 | _ tso/lec 13818-3 [24] | 1€C61937-4[15] } | 2 | 0 | 
Ea 


MPEG-1 BOAR C en IEC 61937-4 [15] 1 {1 4 channels 
Layer 1 or Layer 2 


Data Byte 2, bits SF2, SF1, and SFO, when coded, indicate the audio sampling frequency in the 
audio stream. These bits shall be set according to Table 38. A Sink capable of receiving digital 
audio shall determine the audio sampling frequency by parsing the audio stream header when 
SF=0 (SF2=0, SF1=0, SFO=0). 


Data Byte 2, bits SS1 and SSO, when coded, indicate the number of bits per audio sample in the 
audio stream. These bits shall be set according to Table 38. A Sink capable of receiving digital 
audio shall determine the number of bits per audio sample by parsing the audio stream header 
when SS=0 (SS1=0, SSO=0). 


Table 38 - Audio InfoFrame Data Byte 2 


48 kHz 


88.2 kHz 
96 kHz 


82 


CTA-861-H 


Data Byte 3, bits CXT4, CXT3, CXT2, CXT1, and CXTO, when coded and when the CT field in Data 
Byte 1 is set to 15, indicate the audio format type of the audio stream. The CXT4-CXT0O bits shall 
be set to 0x00 (CXT4=0, CXT3=0, CXT2=0, CXT1=0, CXTO=0) when the CT field in Data Byte 1 is 
set to a value other than 15. When the CT field in Data Byte 1 is set to 15 (CT3=1, CT2=1, CT1=1, 
CTO=1) the CXT bits may be set according to Table 39. When CXT=0 (CXT4=0, CXT3=0, CXT2=0, 
CXT1=0, CXTO=0) a Sink capable of receiving digital audio shall determine the audio format by 
analyzing the value of the CT field in Data Byte 1 or by parsing the audio stream header. 


Table 39 - Additional Audio Format Code Extension Values (Data Byte 3) 


; ; Audi T 
CXT pucle: Coalne Audio Stream Encoding Standard Hele Ste amiransport 
Extension Type Standard 


Refer to Audio Coding Type (CT) field in Data Byte 1 


RA GB/T 22726 [39] IEC 61937-12 [22] 


MPEG-4 HE AAC + ISO/IEC 14496-3 [25], 
MPEG Surround ISO/IEC 23003-1 [26] IEC 61937-11 [21] 


MPEG-4 AAC LC + ISO/IEC 14496-3 [25], 
MPEG Surround ISO/IEC 23003-1 [26] IEC 61937-11 [21] 


ETSI TS 103 190 [45] IEC 61937-14 [47] 
L-PCM 3D Audio IEC 60958-3 [12] 
OxOE - Ox1F 
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6.6.2 Speaker Mapping and Down-mix Information 


Data Bytes 4 and 5 apply only to multi-channel (i.e., more than two channels) Uncompressed 
Audio. 


Data Byte 4 contains information that describes how various speaker locations are allocated to 
transmission channels. Data Byte 5 contains information that tells the Sink how much the 
Source attenuated the audio during a down-mixing operation. The down-mix inhibit flag 
(DM_INH) describes whether audio output is permitted to be down-mixed or not. This flag is 
used in DVD Audio applications (see Table 43). 


The labels and placements of speakers used in CTA-861 are defined in Figure 6 and Table 40. 
Note that the speaker location names are informatively associated to the angular speaker 
locations as per Rec. Rec. ITU-R BS.2051 [139]. The Speaker labels and descriptions in Table 40 
are consistent with those in ISO/IEC 62574 [43]. 


Annex K contains additional information concerning speaker placement relationships between 
CTA-861 and other standards, and Annex Q describes how the naming convention in Table 40 
relates to prior revisions of CTA-861. 
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StL BtFC jem 
LFE1 LFE2 


FLw 
sil 


Figure 6 - Speaker Placement 
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Table 40 - Speaker Placement 


Position Description 
Front Left 
Front Right 
Front Center 


mn 
— 


Low Frequency Effects 1 
Back Left 

Back Right 

FLc Front Left of Center 

FRc Front Right of Center 
BC Back Center 

LFE2 Low Frequency Effects 2 
SiL Side Left 

SiR Side Right 

TpFL Top Front Left 

TpFR Top Front Right 

TpFC Top Front Center 

TpC 
TpBL 
TpBR 
TpSiL 
TpSiR 
TpBC 
BtFC 


Top Center 

Top Back Left 

Top Back Right 
Top Side Left 

Top Side Right 

Top Back Center 
Bottom Front Center 
BtFL Bottom Front Left 
BtFR Bottom Front Right 
FLw Front Left Wide 
Front Right Wide 
Left Surround 


mn 


Rw 
S 
S 


Ww} Tr 


Right Surround 
reserved 
reserved 
reserved 
reserved 


NOTE — 

F: indicates speakers forward of the primary listening position 

B: indicates speakers behind the primary listening position 

Si: indicates speaker to the side of the primary listening position 

Tp: indicates speakers above the normal seating position of the listeners 
Bt: indicates speakers below the normal seating position of the listeners 


TpC: is directly over the primary listening position. All speakers are assumed to be generally 
pointing at the primary listening position. 
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Data Byte 4 contains information that describes how various speaker locations are allocated to 
transmission channels. Channel allocation is shown in Table 41 (see Annex K for additional 
information concerning audio channel allocation relationships between CTA-861 and other 
standards). 


Codes OxFE and OxFF in Data Byte 4 designate an alternate delivery order of the L-PCM audio, 
described in Sections 6.6.3 and 6.6.4. 


8/ 
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Table 41 - Audio InfoFrame Data Byte 4 


pian Channel Number 


o JoJo fof foJo fos Ff es is 
o jo fo jo [2 jo jo [1 oxwoo ff rs fis 

o jo fo fo [2 jo ja fo foxom ff irs fis rc 

o jo jo jo ja jo ja ja joxop ff rs fis fre 

o jo fo fo [2 |r jo fo foxwoc | [ec fers fis | 

o 6 e  e ee e ee LFEI 


p foo fs Jo fr fo fous reefer 
o jo fo [2 fo ja ja [a fora? |rre fre ff rc ure 
oo Jor fa fo Joo Jous frre ne Jue. |. Ir 


2 Speaker positions RLC/RRC for CA=0x10-0x13 have been replaced by BL/BR, respectively. RLC/RRC have been deprecated as 
unique speaker locations as BL/BR are logically the same speaker locations. This does change the functionality of the Legacy 
mapping of speaker locations to transmission channels. For Table 41, this is a documentation change only. 
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Table 41 - Audio InfoFrame Data Byte 4 (continued) 


CA CA 
Channel Number 
(binary) (hex) 


eee ee ee ee 
ae ee ee ee ee 
eee eee ie ee PY 
i Rk a a ee (ccc i A 
i ee 
Ge Pal A oN i aad All Mee ll A I clo 
Re ee eee eee ee Pe 
Ga ta a alll i AU cl lL 
eet ee ee ft 
Pe ol A na ML (a i a cM 
Ee eee ee ee ee Pee 
Ca el i a a ce tal wc cc cA ca ca GL 
rere ere ee ee Pe 
eee ed 
Er ee eee ee 
CeCe eee Lee De ee ee 
oD SAS Ae oe le Le a 

ee Ee ee ee edo Ee 
Ea a iol a alec 


Sei 

111414641 ##+$%46 +41 ~=+41 OxFE Channels delivered according to the Speaker Mask (see Section 
6.6.3) 

Channels delivered according to Channel Index (see Section 
6.6.4) 


The Sink’s speaker allocation is not always the same as that contained within the Source’s 
audio. In this case, the Source should down mix the audio in order to properly meet the Sink’s 
speaker configuration. In actual implementations, all down-mix coefficients are equally 
attenuated to prevent calculation overflows. The total sound level becomes lower after down- 
mixing. For this reason, the Level Shift Value should also be transmitted to the Sink to ensure 
the proper sound level is achieved. 


Reserved 
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Data Byte 5 contains Level Shift Information, a Down-mix Inhibit Flag, and LFE playback level 
information. 


The values of attenuation associated with the Level Shift Values (LSVO-LSV3) are shown in Table 
42. 


Table 42 - Audio InfoFrame Data Byte 5, Level Shift Value 


LSV3 LSV2 LSV1 LSVO Level Shift Value 


OdB 
1dB 
2dB 
3dB 

dB 
5dB 
6dB 
7dB 
8dB 
9dB 


a 
i 


1 
1 
1 
1 
1 
1 
1 


The Down-mix Inhibit Flag is shown in Table 43. 
Table 43 - Audio InfoFrame Data Byte 5, Down-mix Inhibit Flag 


| DM_INH | Describes whether the down mixed stereo output is permitted or not. 
Permitted or no information about any assertion of this 


oT 


The LFE playback level information shown in Table 44 can be used to communicate one element 
of techniques used to balance low frequency audio information when audio is presented ina 
variety of speaker configurations combining speakers and subwoofers. One such technique uses 
a 10dB boost to bring low frequency information in the LFE channel of 5.1 channel audio 
systems in acoustical balance with the low frequency information present at other speakers. 
This table is a simple way of communicating from Source-to-Sink that this element of low 
frequency balancing has been employed. If audio data does not contain a LFE signal, then the 
LFEPBL field shall be ignored. 
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Table 44 - Audio InfoFrame Data Byte 5, LFE Playback Level Information 


LFEPBL1 LFEPBLO Describes what value is used for LFE playback level comparing with other 
channel signal. 


Unknown or refer to other information 


1 + 10 dB playback 


Note: The Source may set the LFEPBL fields according to encoding rules of source content. Typically the 
Audio/Visual content use +10dB and Audio contents use OdB. The Sink may adjust the LFE signal level and not the 
total output level for subwoofer in down mixing case. If the audio data does not contain a LFE signal, the LFEPBL 
field shall be ignored. 


6.6.3 Delivery According to the Speaker Mask (Data Byte 4 = OxFE) 


Data Bytes 6 to 8 of the InfoFrame shown in Table 35 correspond to the SPM Bytes defined in 
Table 100 and these bytes constitute the Soeaker Mask. The source shall not declare channels 
in the InfoFrame that were not declared as available in the RCD. All channels declared in the 
InfoFrame shall be present in the audio delivery. 


In the SPM of the RCD (Table 100), many of the flags describe a pair of speakers (e.g. FL/FR), but 
some describe a single speaker (e.g. LFE1). When a source device is preparing audio for a room 
described in this manner, both speakers of a pair are always assumed to be present. 


For systems conforming to ISO 60958, speaker feeds are always packed in channel pairs. For 
example in a 5.1 speaker system, LFE1 and FC are packed together in a L-PCM transmission. 


The ordering of the L-PCM channels feeding into the speakers shall be according to the 
following rules: 


1) Channels shall be sent consecutively in the order indicated in the SPM portion of the 
Room Configuration Descriptor Data Block, starting from bit 0, Data Byte 1. 

2) Channel pairs shall always be sent together in the order of Left/Right 

3) Single channels shall be sent in the order of the first flag/next flag, e.g. LFE1/Center. 

4) \|f one or more channel pairs exists between two single channels, then the second single 
channel shall be brought forward to fill the vacancy ahead of the pairs. 

5) If an odd number of channels are being presented, then an inactive channel shall occupy 
the second channel of the channel pair carrying the single channel. 


Example: 
A source is sending the following channels: 

FL, FR, LFE1, FC, BL, BR, BC, TpFL, TpFR, LFE2 
The order of the channel pairs shall be as follows: 


FL/FR, 
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LFE1/FC, 
BL/BR, 
BC/LFE2, 
TpFL/TpFR 


6.6.4 Delivery by Channel Index (Data Byte 4 = 0xFF) 


A Source shall only deliver audio data by channel index when a Speaker Location Data Block is 
available for all channels being utilized by the Source. 


If the delivery by Channel Index is used, it will be used exclusively, and delivery by speaker mask 
(as described in Section 6.6.3) will not be used. 


When Delivery by Channel Index is being used, Data Bytes 6, 7, 8 and 9 in the Audio InfoFrame, 
shown in 


Table 36, indicate which channels are being delivered. Bits CIDOO to CID31 correspond to 
Channel Index 0 to Channel Index 31 respectively, as assigned in the Speaker Location 
Descriptors. 


The Source shall only deliver audio to Channel Indices that were declared in a Speaker Location 
Data Block. For each Channel Index that is represented in the audio transmission, the 
corresponding CID flag of the InfoFrame shall be set to 1. All other CID flags shall be set to 0. 


The ordering of the L-PCM channels in the audio transmission shall directly correspond to the 
Channel Index from the lowest value to the highest, not make any exception for paired (L/R) 
channels, and only include channels indicated as Active in the corresponding Speaker Location 
Descriptor (see Table 102). 


6.6.5 Additional Audio InfoFrame Information 


The value of the LFEPBL field, in Audio InfoFrame Data Byte 5, shall apply to all LFE channels in 
use (i.e., LFE1 and LFE2). 


6.7 MPEG Source InfoFrame 


The MPEG Source InfoFrame describes aspects of the compressed video stream that were used 
to produce the uncompressed video. In many cases, the compressed source is MPEG2, although 
this InfoFrame can be applied to any similar compressed format. Some Sinks may use this 
information to improve the displayed Picture. 


Note: Implementation of the MPEG Source InfoFrame is not recommended due to 
issues that have been reported and not resolved. The information contained in this 
section is reserved for future use and enhancement. 


Transmission of this information by the Source is optional. Use of this information by the Sink is 
also optional. 
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If the Source supports the transmission of the MPEG Source InfoFrame and if it determines that 
the Sink is capable of receiving the MS InfoFrame (i.e., the Sink has included CTA Extension 
Version 3 in EDID), then this information should be sent once per Video Frame when applicable. 
The data applies to the next full frame of video data. 


The format of the MPEG Source InfoFrame is shown in Table 45. 


Table 45 - MPEG Source InfoFrame format 


InfoFrame Type Code InfoFrame Type = 0x05 
InfoFrame Version Number Version = 0x01 


Length of MPEG Source Length of MPEG Source InfoFrame (10) 
InfoFrame 


Data Byte 1 MB#0 (MPEG Bit Rate: Hz Lower > Upper) 
Data Byte 2 MB#1 
Data Byte 3 MB#2 


MB#3_( Upper Byte ) 
F100=0 


Data Bytes 1-4 give the MPEG bit rate. The MPEG Bit Rate is stored as a 32-bit number and is 
expressed in Hertz. MB#O contains the least significant byte while MB#3 contains the most 
significant byte. If the MPEG Bit Rate is unknown or this field does not apply, then all of the bits 
in Data Bytes 1-4 shall be set to O. 


Example: 
10 Mbps > 10,000,000 Hz (dec.) > 0x00989680 Upper ... Lower Byte 
Byte 1 MB#0 Ox80 Lower Byte 
Byte 2 MB#1 0x96 
Byte 3 MB#2 0x98 
Byte 4 MB#3 Ox00 Upper 


MF1 and MFO in Data Byte 5 (see Table 46) designate whether the current field/frame was 
generated from an |, B, or P picture from the source MPEG stream. If this is unknown or does 
not apply, then the field shall be set to “unknown.” 


In some cases, the Source creates 60 field/second video from 24 frames/second source 
material. 3:2 pull-down is commonly used. FRO can be used to designate whether a field is a 
repeated field or not. The Sink can use this information to improve the picture. If 3:2 pull-down 
does not apply to the current video decoding, then all of the fields/frames should be marked as 
“New field.” 
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Table 46 - MPEG Source InfoFrame Data Byte 5 


Field Repeat 
(for 3:2 pull-down) 


iar ae New field (Picture) Unknown (No Data) 


Repeated Field 


6.8 NTSC VBI InfoFrame 


The NTSC VBI InfoFrame provides for the carriage of SCTE 127 [28] payloads containing VBI 
data. Transmission of this information by the Source is optional. Use of this information by the 
Sink is also optional. However, when present, Sinks can extract this information for direct use, 
or when analog NTSC outputs are present, regenerate relevant VBI data along with the video 
and audio. 


This InfoFrame should be sent once per Video Frame when applicable. The data applies to the 
next full frame of video data. 


The format of the NTSC VBI InfoFrame is shown in Table 47. 
Table 47 - NTSC VBI InfoFrame 


InfoFrame Type Code InfoFrame Type = 0x06 
InfoFrame Version Number Version = 0x01 


Length of NTSC VBI 


Length of NTSC VBI InfoFrame — total number of bytes following this 
field 


Data Bytes 1...Length The PES data_field() structure of SCTE 127, Table 2 [28] 


The stuffing bytes should be omitted before transmission by the Source. 


In order to maximize the possibility of operation with existing silicon, Sources should constrain 
the NTSC VBI InfoFrame’s payload to 27 bytes or less (e.g., a 31-byte HDMI InfoFrame less 3- 
byte header and 1-byte checksum leaves 27 bytes for payload). This means the PES_data_field() 
structure would be constrained (modified if necessary) to 27 bytes. NABTS (which requires 37 
bytes) should not be encoded. 


Note: 27-byte payload is adequate, for example, for two fields of AMOL96 and one field 
of TVG2X per frame. 


6.9 Dynamic Range and Mastering InfoFrame 


The Dynamic Range and Mastering InfoFrame carries data such as the Transfer Function and 
the Static Metadata associated with the dynamic range of the video signal. 


If the Source supports the transmission of the Dynamic Range and Mastering InfoFrame and if 
the Source determines that the Sink is capable of receiving that InfoFrame: 
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e The Source shall send the Dynamic Range and Mastering InfoFrame once per Video Field 
if the Source is sending a video signal that requires any Data Byte 1 to n in Table 48 to 
be non-zero (i.e., HDR metadata or other uses requiring non-zero data). 

e The Source may send the Dynamic Range and Mastering InfoFrame once per Video Field 
when the Data Bytes 1 to n in Table 48 are all zero. 


The Source shall not send a Dynamic Range and Mastering InfoFrame to a Sink that does not 
have at least one of the TF_n bits in the HDR Static Metadata Data Block (Section 7.5.13) set to 
‘1’. The Source shall not send EOTF (Transfer_Function) = n to a Sink that has the corresponding 
TF_n bit set to ‘0’. 


The format of the Dynamic Range and Mastering InfoFrame is shown in Table 48. 


Table 48 - Dynamic Range and Mastering InfoFrame 


Version = Ox01 
Length of following HDR Metadata InfoFrame 


F27=0 F26=0 F25=0 F24=0 F23=0 


Static_Metadata_ Descriptor 


Data Byte 1 Transfer_Function identifies the Electro-Optical Transfer Function (EOTF) or Opto- 
Electronic Transfer Function (OETF) used in the video signal. 


Table 49 - Data Byte 1 — Transfer Function 


Transfer_Function Transfer Function used in the signal 
Traditional gamma — SDR Luminance Range 


Traditional gamma — HDR Luminance Range 


Perceptual Quantization (PQ) based on SMPTE ST 2084 [41]1® 
Hybrid Log-Gamma (HLG) based on Rec. ITU-R BT.2100 [48] 
Reserved for future use 


“Traditional Gamma” indicates that the Transfer Function used in the video signal is consistent 
with the requirements in CTA-861. If the Colorimetry bits CO and C1 in the AVI InfoFrame are 
both zero (indicating “No Data”), then the transfer function shall be consistent with the 
requirements in Section 5.1, “Default Encoding Parameters”. If either of bits CO and C1 in the 


16 The Transfer Function 2 is equivalent to the Transfer Function in Rec. ITU-R BT.2100, where it is referred to as Perceptual 
Quantization (PQ). 
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AVI Info Frame are non-zero, then the transfer function shall be consistent with the colorimetry 
standard indicated by the Colorimetry (CO and C1), Extended Colorimetry (ECO to EC2) and 
Additional Colorimetry Extension (ACEO to ACE3) bits in the AVI InfoFrame. See Table 6 for the 
transfer characteristics of supported colorimetries. 


The SMPTE ST 2086 [42] metadata contained in Data Bytes 3-22 of Table 51 - Static Metadata 
Descriptor Type 1 may be used by the Source to provide information about the mastering 
display color volume characteristics associated with the video signal. 


If “Traditional Gamma — SDR Luminance Range” is indicated, then the maximum encoded 
luminance is typically mastered to 100 cd/m. 


If “Traditional Gamma — HDR Luminance Range” is indicated, then the maximum encoded 
luminance is understood to be the maximum luminance of the Sink device. 


Data Byte 2 Static_Metadata_Descriptor_ID identifies the structure used in Data Byte 3 and 
higher. 


Table 50 - Data Byte 2 — Static_Metadata_Descriptor_ID 


Static_Metadata , 
a — | Metadata Descriptor 
Descriptor_ID 


OO | Static Metadata Type 1 
Reserved for future use 


6.9.1 Static Metadata Type 1 


When Static_Metadata_ Descriptor_ID = 0, Static _Metadata_Descriptor uses the structure 
defined in Table 51 that was defined at the request of the Blu-ray Disc Association, see [138]. 
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Table 51 - Static Metadata Descriptor Type 1 
DataBytenumber | Contents | Group 

Data Byte 3 

Data Byte 4 

Data Byte 5 

Data Byte 6 

Data Byte 7 

Data Byte 8 ; 

Data Byte 9 

Data Byte 10 

Data Byte11 

Data Byte 12 

Data Byte 13 

Data Byte 14 

Data Byte 15 

Data Byte 16 

Data Byte 17 white_point_y, LSB 

Data Byte 18 white_point_y, MSB 

Data Byte 19 

Data Byte 20 

Data Byte 21 See CC 
Data Byte 23 
Data Byte 24 


Data Byte 25 Maximum Frame-average Light Level, LSB 
Data Byte 26 Maximum Frame-average Light Level, MSB 


Data Byte 22 min_display_mastering_luminance, MSB 


Data Bytes 3 — 22 contain the Display Mastering data defined in SMPTE ST 2086 [42]. 


Data Bytes 3 — 18 are coded as unsigned 16-bit values in units of 0.00002, where O0x0000 
represents zero and O0xC350 represents 1.0000. 


Data Bytes 3 — 18 describe the chromaticity of the Red, Green and Blue color primaries and of 
the white point of the mastering display. 


All possible mappings of the chromaticity of Red, Green and Blue color primaries to indices O, 1, 
and 2 are allowed and shall be supported by the sink. 


The correspondence between Red, Green and Blue color primaries and indices O, 1, or 2 are 
determined by the following relationship: 


The Red color primary corresponds to the index of the largest display_primaries_x[] 
value. 


The Green color primary corresponds to the index of the largest display_primaries_y[] 
value. 


The Blue color primary corresponds to the index with neither the largest 
display_primaries_y[] value nor the largest display_primaries_x[] value. 
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Data Bytes 19 — 20 specify a value for the max_display_mastering luminance. This value is 
coded as an unsigned 16-bit value in units of 1 cd/m, where 0x0001 represents 1 cd/m? and 
OxFFFF represents 65535 cd/m. 


Data Bytes 21 — 22 specify a value for the min_display_mastering_ luminance. This value is 
coded as an unsigned 16-bit value in units of 0.0001 cd/m?, where 0x0001 represents 0.0001 
cd/m? and OxFFFF represents 6.5535 cd/m. 


Data Bytes 23 — 24 contain the Maximum Content Light Level (MaxCLL). This value is coded as 
an unsigned 16-bit value in units of 1 cd/m, where 0x0001 represents 1 cd/m? and OxFFFF 
represents 65535 cd/m?*.*” The algorithm used to calculate MaxCLL is defined in Annex P 
section N. 


Data Bytes 25 — 26 contain the Maximum Frame-Average Light Level (MaxFALL). This value is 
coded as an unsigned 16-bit value in units of 1 cd/m, where 0x0001 represents 1 cd/m? and 
OxFFFF represents 65535 cd/m72.?® The algorithm used to calculate MaxFALL is defined in Annex 
P section P.2. 


The data in Data Bytes 3 — 26 are arranged into groups, as indicated in Table 51 - Static 
Metadata Descriptor Type 1 above. When all of the Data Bytes in a group are set to zero, then 
the Sink shall interpret the data for that group as unknown’”’. It is permissible to send a Static 
Metadata Descriptor (Data Bytes 3 through n) containing a subset of data that is constructed 
with partial zeroes. 


If a Source does not have SMPTE ST 2086 [42] metadata to send, then Data Bytes 3-22 shall be 
populated with zeroes to indicate the data is not provided. 


17 For MaxCLL, the unit is equivalent to cd/m? when the brightest pixel in the entire video signal has the chromaticity of the 
white point of the encoding system used to represent the video signal. Since the value of MaxCLL is computed with a max() 
mathematical operator, it is possible that the true CIE Y Luminance value is less than the MaxCLL value. This situation may occur 
when there are very bright blue saturated pixels in the the video signal, which may dominate the max(R,G,B) calculation, but 
since the blue channel is an approximately 10% contributor to the true CIE Y Luminance, the true CIE Y Luminance value of the 
example blue pixel would be only approximately 10% of the MaxCLL value. 


18 For MaxFALL, the unit is equivalent to cd/m? when the maximum frame average of the entire video signal corresponds to a 
full-screen of pixels that has the chromaticity of the white point of the encoding system used to represent the video signal. The 
frame-average computation used to compute the MaxFALL value is performed only on the active image area of the image data. 
If the video signal is a "letterbox" format (e.g. where a 2.40:1 aspect ratio is put inside a 16:9 image container with black bars 
on the top and bottom of the image), the black bar areas are not part of the active image area and therefore are not included in 
the frame-average computation. This allows the MaxFALL value to remain an upper bound on the maximum frame-average 
light level even if image zooming or pan/scan is performed as a post-processing operation. 


19 For MaxCLL and MaxFALL, this may occur when information about the content light level has not been, or cannot be, 
provided — for example, content that is rendered or broadcast in real-time, or pre-processed content that was delivered 
without information about the content light level. 
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6.10 Extended InfoFrame 


The Extended InfoFrame is intended to carry larger amounts of data than is allowed by the 
InfoFrame mechanism described in Sections 6.1 to 6.9. 


The content of the Extended InfoFrame is shown in Table 52: 


Table 52 - Extended InfoFrame 


Data Byte 1 Extended InfoFrame Data Byte 1 
Data Byte n Extended InfoFrame Data Byte n 


Extended InfoFrame Type Code — a 2-byte number identifying the data carried in this Extended 
InfoFrame. Extended InfoFrame Type Codes are shown in Table 53: 


Table 53 - Extended InfoFrame Type Codes 


Value Extended InfoFrame Type 


0x0000 


Ox0001 HDR Dynamic Metadata according to the syntax specified in 
Annex R 


Ox0002 HDR Dynamic Metadata carried in Supplemental 
Enhancement Information (SEI) messages according to ETSI 
TS 103 433-1 [50] 


Ox0004 HDR Dynamic Metadata carried according to the syntax 
specified in Annex S 


0x0005-OxOOFF 


0x0003 HDR Dynamic Metadata carried in Colour Remapping 
Information SEI] message according to Rec. ITU-T H.265 [52] 


0x0100 Graphics Overlay Flag carried according to the syntax 
specified in Annex T 


All other values 


Length of Extended InfoFrame — a 2-byte value indicating the length of the following Extended 
InfoFrame data. 


Data Byte 1 to n — The Extended InfoFrame Data identified by the Extended InfoFrame Type 
Code. 


A Source shall not send the same Extended InfoFrame Type more than once within an MTW. 


The data contained in the HDR Dynamic Metadata Extended InfoFrame applies to the Active 
Pixels that follow the MTW. 


If the Source supports transmission of a type of HDR Dynamic Metadata Extended InfoFrame 
(as indicated by the relevant Extended InfoFrame Type) and if it determines that the Sink is 
capable of receiving that information, the Source may send the HDR Dynamic Metadata 
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Extended InfoFrame in conjunction with the video encoded according to the rules of the 
Extended InfoFrame Type. 


6.10.1 HDR Dynamic Metadata Extended InfoFrame 


When the Extended InfoFrame Type Code is set to 0x0001, 0x0002, 0x0003, or 0x0004, the 
Extended InfoFrame carries HDR Dynamic Metadata. The HDR Dynamic Metadata Extended 
InfoFrame contains the HDR Dynamic Metadata that might typically be carried in Supplemental 
Enhancement Information (SEI) messages. 


When the Extended InfoFrame Type Code is set to 0x0100, the Extended InfoFrame carries the 
Graphics Overlay Flag, which applies to the HDR Dynamic Metadata as specified in Annex T. 


Figure 7 depicts the transfer timing and applicability of the HDR Dynamic Metadata Extended 
InfoFrame data relative to the video lines. The Metadata Transmission Window (MTW) is 
defined as the period of time beginning with the first Active Pixel of a Video Frame and ending 
with the final Blank Pixel of the final Blanking Line in a Vblank period. As shown by the arrow in 
Figure 7, HDR Dynamic Metadata transmitted during the MTW applies to the Active Pixels that 
immediately follow the MTW. Standards and specifications that incorporate CTA-861 may 
reduce the period of the MTW by delaying the start of the MTW and/or ending the MTW on an 
earlier Blanking Line. 


First Active Pixel of the Top Line First Active Pixel of the Top Line 


Top Line Bottom Line Top Line Bottom Line 


Data 
Enable 


Metadata Transmission Window 


Letters a, b, c, and d represent line numbers. 


Figure 7 - HDR Dynamic Metadata Transmission Window and Metadata Applicability 
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The HDR Dynamic Metadata Extended InfoFrame is shown in Table 54 below: 


Table 54 - HDR Dynamic Metadata Extended InfoFrame common structure 


Extended InfoFrame Type Code 
Length (n) of Extended InfoFrame 


Data Byte 1 Application-specific Data 1 
Application-specific Data n 


When Extended InfoFrame Type Code is set to 0x0001, the Application-specific Data in Data 
Bytes 1-n is the Display Management Message Data that is specified in Annex R. 


When Extended InfoFrame Type Code is set to 0x0002, the Application-specific Data in Data 
Bytes 1-n is a concatenation of the Supplemental Enhancement Information (SEI) messages 
described in the Annexes of ETSI TS 103 433-1 [50] in any order. The data bytes defining 
payloadType and payloadSize as defined in Rec. ITU-T H.264 [51] and Rec. ITU-T H.265 [52] are 
included in the Application-specific Data. The processing mode to be used by the Sink with the 
HDR Dynamic Metadata is indicated by s|_ hdr_mode_value_minus1 as described in 

ETSI TS 103 433-1 [50] Annex G.3. 


When Extended InfoFrame Type Code is set to 0x0003, the Application-specific Data in Data 
Bytes 1-n is the Colour Remapping Information (CRI) Supplemental Enhancement Information 
(SEI) message described in Rec. ITU-T H.265 [52]. The data bytes defining payloadType and 
payloadSize as defined in Rec. ITU-T H.265 [52] are included in the Application-specific Data. 


When Extended InfoFrame Type Code is set to 0x0004, the Application-specific data in Data 
Bytes 1-n is the Dynamic Metadata for Color Volume Transform — Application #4 of SMPTE ST 
2094-40 [55] standard that is specified in Annex S. 


A Source shall not send an Extended InfoFrame Type 0x0001, 0x0002, 0x0003, or Ox0004 to a 
Sink that does not indicate support for that Extended InfoFrame Type in the Sink’s HDR 
Dynamic Metadata Data Block. A Source shall not send more than one type of HDR Dynamic 
Metadata Extended InfoFrame Types 0x0001, 0x0002, 0x0003, 0x0004 within the same MTW. A 
Source may send a Graphics Overlay Flag Extended InfoFrame when an HDR Dynamic Metadata 
Extended InfoFrame Type 0x0001, 0x0002, 0x0003, or 0x0004 is present. 


When used, the HDR Dynamic Metadata Extended InfoFrame shall be sent every MTW and shall 
contain the data relevant to the immediately following Active Video period. Data in each HDR 
Dynamic Metadata Extended InfoFrame may be the same as that sent in previous HDR Dynamic 
Metadata Extended InfoFrames. 


Where the information contained in the Dynamic Range and Mastering InfoFrame conflicts with 
the same data in the HDR Dynamic Metadata Extended InfoFrame, then the data in the HDR 
Dynamic Metadata Extended InfoFrame shall take priority. 
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6.10.2 Graphics Overlay Flag Extended InfoFrame 


When the Extended InfoFrame Type Code is set to 0x0100, the Extended InfoFrame carries the 

Graphics Overlay Flag, which applies to the HDR Dynamic Metadata as specified in Annex T. The 
Application-specific Data in Data Bytes 1-n is the Graphics Overlay Flag carried according to the 
syntax specified in Table 173. 


A Source shall not send an Extended InfoFrame Type 0x0100 to a Sink that does not indicate 
support for that Extended InfoFrame Type in the Sink’s HDR Dynamic Metadata Data Block. 


A Source shall not send a Graphics Overlay Flag Extended InfoFrame containing Extended 
InfoFrame Type 0x0100 unless it is also sending an HDR Dynamic Metadata Extended InfoFrame 
containing an Extended InfoFrame Type 0x0001, 0x0002, 0x0003, or 0x0004 that applies to the 
same frame. 


The Graphics Overlay Flag follows the same transfer timing and applicability as shown in Figure 
7. 


The format of the Graphics Overlay Flag Extended InfoFrame is shown in Table 54. 
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7 EDID DATA STRUCTURE 


Extended Display Identification Data (EDID) was created by VESA to enable plug and play 
capabilities of displays (Sinks). This data, which is stored in the Sink, describes Video Formats 
that the DTV (display) is capable of receiving and rendering. The information is supplied to the 
Source, over the interface, upon the request of the Source. The Source then chooses its output 
format, taking into account the format of the original video stream and the formats supported 
by the Sink. Format conversions necessary to supply video to the Sink should be determined 
according to recommendations in Annex F. 


The EDID data structures version 1, revision 3 [9] and newer are known as Enhanced EDID (E- 
EDID). Sources should interpret and Sinks should implement the EDID data structure according 
to the VESA E-EDID Implementation Guide [119]. Sink implementers should verify a Sink’s EDID 
data structure using the VESA E-EDID Verification Guide [122]. The Sink shall support E-DDC 
[133] as the method of transporting EDID information. A Source shall be capable of using E-DDC 
[133] to read the entire EDID since critical information may not otherwise be readable if the 
Sink contains a large EDID. 


Some Sinks may contain more than 2 blocks of EDID data. For example, the Sink may include a 
second CTA-861 Extension Block, a VESA DI-EXT Block (as defined in VESA DI-EXT [118]) ora 
VTB-EXT Block (as defined in VESA VTB-EXT [125]). In this case the Sink is required to support E- 
DDC Addressing (using the Segment Pointer) as defined in VESA E-DDC [133]. It is also 
recommended that the Source be capable of reading and parsing more than 2 blocks of EDID 
data. For more information on E-DDC addressing refer to the VESA E-DDC Standard [133]. 


EDID Block 0 contains both version and revision numbers. The version number indicates the 
data structure of Block 0, which remains backwards compatible as the revision number 
changes. Therefore, a Source should continue parsing a recognized structure version — even if 
it encounters an unexpected revision number. 


The Sink shall protect its EDID from accidental corruption resulting from communication errors 
by write-protecting its contents. 


See Annex A and Annex D for example EDIDs. 


7.1 Use of CTA Extensions 


Two of the four 18-byte descriptor slots contained in EDID Block O are designated for a Monitor 
Range Limits Descriptor and a Monitor Name Descriptor. Users of CTA-861 should note that 
future alternate usage of these descriptors is possible, including replacing them with additional 
Detailed Timing Descriptors; therefore, dependency upon data in these descriptors should be 
avoided. Consequently, the E-EDID standard provides a method for including only two Detailed 
Timing Descriptors. 


To accommodate additional Detailed Timing Descriptors, the CTA Extension has been defined. 
The tag (0x02) for this extension, previously reserved within VESA, has now been assigned to 
CTA for the purposes of CTA-861. Therefore, further changes to this structure are under the 
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control of CTA. It is referred to in CTA-861 as the CTA Extension. Section 7.3 defines the 
structure of the CTA Extension. 


7.2 Describing Video Formats in EDID 


Two methods of describing Video Formats are used in CTA-861: VESA-standard data structures 
and CTA Short Video Descriptors. The former includes the following: 


e Established Timings in Block 0 (IT Timing Formats only) 

e Standard Timings in Block 0 (IT Timing Formats only) 

e 18-byte Detailed Timing Descriptors in Block 0 and CTA Extensions 

e 20-byte Detailed Timing Descriptors in CTA Extensions (IT Timing Formats only) 
e 1-and 2-byte Code indices in CTA Extensions (IT Timing Formats only) 

e 6-or 7-byte CVT-based descriptors in CTA Extensions (IT Timing Formats only) 


The Sink shall declare support in its EDID for all of the video formats that it supports. The 
640x480 @60Hz flag, in the Established Timings area, shall always be set, since the 640x480p 
format is a mandatory default timing: both Sinks and Sources shall support this video format at 
24bpp RGB as a minimum point of interoperability. The Source should not transmit video 
formats that are not contained within the EDID to which it is attached, unless it also 
implements a UI test that verifies good operation with the user. This methodology should also 
be used in the case of a bad or missing EDID when switching video formats. If the Source does 
not otherwise know the Sink's capabilities, and if the Source cannot successfully read a Sink’s 
EDID, the Source shall output 640x480p 24bpp RGB. 


When using CTA Extension Version 1, all of the CTA Video Formats listed in E-EDID are 
described using Detailed Timing Descriptors. No matter which CTA Extension is used, there is 
also room for two Detailed Timing Descriptors in EDID Block 0. CTA Extension Version 3 can 
include a combination of Detailed Timing Descriptors and Short Video Descriptors. 


Ifa Version 3 CTA Extension has been included in EDID, all CTA Video Formats shall be 
advertised using Short Video Descriptors, even if they are also advertised using any VESA- 
standard data structures (see Section 7.2.1). 


Even though Short Video Descriptors are available in the Version 3 CTA Extension, there is still a 
need to use Detailed Timing Descriptors if full backward compatibility with legacy Sources is 
desired. Formats with video ID codes of 2 to 5 and 17 to 20 should be advertised using the 
Detailed Timing Descriptors for any Video Formats that the DTV designer wishes to guarantee 
are available to Sources that cannot interpret the Short Video Descriptors and that require 
Detailed Timing Descriptors for proper operation. If sufficient room is not available in the first 
two blocks of the EDID for all of the supported Video Formats, the DTV designer may choose to 
declare support for some of the formats in Short Video Descriptors only. 


A Sink that supports any Dual-Aspect Ratio Timing shall, in its EDID, list the DTD and SVD with 
the Preferred Picture Aspect Ratio before the DTD and SVD with the other Picture Aspect Ratio. 
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7.2.1 Use of EDID Detailed Timing Descriptors 


As required in Section 4, a DTV that declares it is capable of displaying a Video Timing with a 
vertical frequency that is either an integer multiple of 6 Hz or an integer multiple of 6 Hz 
adjusted by a factor of 1000/1001 shall be capable of displaying both versions of the Video 
Timing. DTVs capable of displaying 59.94/60 Hz versions of Video Timings shall declare in the 
EDID structure the 60Hz version of the Video Timing for all Video Formats, except the 240-line 
and 480-line formats, which shall declare 59.94Hz version of the Video Timing. 


Note that the EDID 18-byte Detailed Timing Descriptor allows for the designation of an 
interlaced format. However, there are no provisions to specify separate vertical blanking/sync 
for Field 1 and Field 2. Therefore, for the purposes of CTA-861, the following rules apply for 
interlaced formats: 


a) The Field 1 Vertical Blanking Interval shall equal the Vertical Blanking Lines in the Detailed 
Timing Descriptor. 


b) The Field 2 Vertical Blanking Interval shall equal the Vertical Blanking Lines in the Detailed 
Timing Descriptor + 1. 


c) The Field 1 Vertical Sync Offset shall equal the Vertical Sync Offset in the Detailed Timing 
Descriptor. 


d) The Field 2 Vertical Sync Offset shall equal the Vertical Sync Offset in the Detailed Timing 
Descriptor + 1/2. 


A Sink capable of receiving a Video Format with a Video Identification Code greater than 7 or 
capable of receiving a Dual-Aspect Ratio Timing shall declare different Detailed Timing 
Descriptors in its EDID for each supported Video Timing with a different Picture Aspect Ratio. 
The vertical and horizontal image size parameters in the EDID shall contain numbers that 
describe the aspect ratio of the displayed video (actual dimensions are preferred, but not 
required). 


A special interlaced Video Timing exists (see Figure 5) that modifies the Field 2 Vertical Blanking 
Interval (b) and Vertical Sync Offset (d) values presented here. When all DTD parameters match 
those of Video Identification Code 39 (see Table 55) and a SVD indicating support for code 39 
Video Format also exists, the Field 2 Vertical Blanking Interval (b) and Vertical Sync Offset (d) 
shall instead equal the DTD's "Vertical Blanking Lines" and the DTD's "Vertical Sync Offset” - 
1/2, respectively. 
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Table 55 - Video Timing Code 39 Detailed Timing Descriptor 


_ Sr er 
= Pixel Clock 72.00 MHz 
le 


a 
a [Re —— fs ——— 
Ea 
CC 
CL 
EC EA 


12 0x04 HS Offset: HS Pulse 
Width: VS Offset: VS 
Pulse Width 


ee [ [er [ae 
ie a 


Flags Interlaced, digital separate, 
Vsync polarity is negative, 
Hsync polarity is positive 
(NOTE — stereo mode bits 0, 
5, & 6 may have any value) 


Examples of Detailed Timing Descriptors for the Video Formats are contained in A.2.10. 
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7.2.2 Source Requirements and Recommendations 


Sinks should include a Video Format Preference Data Block (VFPDB, Section 7.5.12) to indicate 
preferential ordering of Video Formats. Preference-by-location, such as ordering of Detailed 
Timing Descriptors (DTD) within the EDID, or VICs within Video Data Blocks, has been 
deprecated. However, some legacy Sources may consider the first 18-byte DTD in Block 0 and 
the first SVD to be preferred, and Sinks may want to take this into consideration when 
populating those items. 


CTA Extension Version 1 is only capable of indicating preference using the first DTD. 


Sources can use the following pseudo-code to determine the preferred video formats: 


If the CTA Extension is Version 1 
The first DTD in Block O is preferred 
Elseif a Video Format Preference Data Block (VFPDB) is present 
Video Formats are listed in order of preference 
Else 
The first DTD in Block O and the first SVD are preferred 
End If 


It is strongly recommended that a Source provide an option of operating in Source Pass-through 
Mode. When operating in Source Pass-through Mode, the Source transmits the video to the 
Sink without performing any interlacing, deinterlacing, or scaling on the transmitted content. A 
Source operating in Source Pass-through Mode determines the supported Video Formats of the 
Sink and utilizes this information to ensure that it passes through only Video Formats supported 
by the Sink. If the Sink supports no corresponding Video Format, then some conversion is 
necessary; the conversion should be to one of the preferred formats, in order of priority. 
Detailed recommendations for Sources and Sinks, plus examples of different conversions are 
illustrated in Annex F. Typically, PCs and game machines locally determine the resolution of the 
content rather than processing pre-recorded or broadcast content at a preset resolution. In 
these cases, it is recommended that the Source generate the content in the first format in the 
EDID that the Source supports. The Source shall read the EDID to determine if a specific format 
is supported. The Source shall only choose an output format listed in the EDID except in the 
following circumstances: 


1) The Source cannot find a format in the EDID, which it supports. 


2) The user manually overrides the automatic behavior. 
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7.3. CTA Extension 


Three versions of the CTA Extension exist. If more than one CTA Extension is included in EDID, 
they shall all be the same version. 


To maintain backward compatibility, newer versions of the CTA Extension include all of the 
fields that were present in the previous versions. Additionally, length fields are provided on 
internal data structures to convey block size and to aid the Source in interpreting the data. 
Having block sizes should help Source devices move from block-to-block, when blocks contain 
corrupt or Vendor-Specific data. Future versions of the CTA Extension are expected to have the 
version number incremented and be backward compatible with previous versions. A current 
generation Source is capable of parsing these future EDIDs exactly as it does existing EDIDs, if it 
ignores the version number. Sources should continue parsing the EDID structure even if an 
unexpected version number is encountered. 


CTA Extension Version 1 only provides a way to supply extra Detailed Timing Descriptors. It is 
still permitted to be used for some Sinks (e.g., limited format DVI displays) but Version 3 is 
more applicable for most devices. 


CTA Extension Version 2 is no longer supported and shall not be included in Sinks. 


CTA Extension Version 3 includes all of the fields and capabilities of Versions 1 & 2, but also 
includes the ability to specify any of the CTA Video Formats using “CTA Short Video 
Descriptors.” It provides the ability for the Sink to specify what types of advanced audio it 
supports using “CTA Short Audio Descriptors.” It also provides a way for the Sink to specify its 
speaker configuration. This information is complementary to the speaker channel allocation 
information that is sent in the Audio InfoFrame. 


If a Sink supports any Video Format with a format code greater than 7, YCgCr color space, 
InfoFrames, or digital audio (e.g., is an HDMI monitor), then it shall include the version 3 (or 
higher) CTA Extension in its EDID data structure. 
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7.3.1 CTA Extension Version 1 


This version of the CTA Extension has been supplanted by Version 3 (see Section 7.3.3) and is 
not recommended for new designs. It only allows an EDID to supply extra Detailed Timing 
Descriptors (DTDs). 


The CTA Extension in Table 56 follows the format described in Section 2.2.1.3 of VESA E-EDID 
Standard [9]. The EDID Extension Tag for this extension shall be Ox02. 


Table 56 - CTA Extension Version 1 (supplanted by Version 3) 


Byte # _Value___| Description Format 
pO x02 Tag (0x02) SS 
pdf xo RevisionNumber 


2 Byte number offset d where 18-byte offset for the byte following the 
descriptors begin (typically Detailed reserved data block. If no data is provided 
Timing Descriptors) in the reserved data block, then d=4. If no 

DTDs are provided, then d=0. 


3 S| Reserved C—C“‘“‘CXd(S;SSet to. 0x0 
a ees Start of reserved data block 


| di | id Endofrreserveddatablock 
| dd] —™~—~™—sSY Start of 18-byte descriptors «|: See Section 3.10.2 of VESA E-EDID 
pn || nimvereteciporinduded [nn 
nUMBEE of f descriptors included 


127 Checksum OxXX = This byte should be programmed 
such that a one-byte checksum (add all 
bytes together) of the entire 128 byte 
block equals Ox00. 
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7.3.2 CTA Extension Version 2 


CTA Extension Version 2 is deprecated and shall not be included in Sinks. See Table 57. 


Table 57 - CTA Extension Version 2 (deprecated) 


| Byte# | Value | Description Format 
pO x02 Tag (0x02) 
1} 0x02 __| Revision Number fT 


Byte number offset d where 18-byte d = offset for the byte following the reserved 
descriptors begin (typically Detailed data block. If no data is provided in the 
Timing Descriptors) reserved data block, then d=4. If d=0, then 
no detailed timing descriptors are provided, 
and no data is provided in the reserved data 
block. 
Total number of native Detailed Timing bit 7 (CTAX_UNDERSCAN) = 1 if Sink 
Descriptors in entire E-EDID structure. underscans IT Video Formats by default. 
Also, indication of underscan support, bit 6 (CTAX_BASIC_AUDIO) = 1 if Sink 
audio support, and support of YCgC is supports Basic Audio. 
included bit 5 (CTAX_YCC444) = 1 if Sink supports 
YCgCp 4:4:4 in addition to RGB. 
bit 4 (CTAX_YCC422 = 1 if Sink supports 
YCgCp 4:2:2 in addition to RGB. 
bits 3-0 (CTAX_NATIVE_DTDS) = total 
number of native DTDs (see Section 2.2 for 
definition of "Native Video Format"). 


Se ae eee Start of reserved data block 
| di | Cd of reserved data block 
Te Start of 18-byte Besctintols See Section 3.10.2 of VESA E-EDID Standard 


Sate — : 
Bumper of f descriptor included 
/OxoO38=F—™T fe es te of /EndofPadding | 
Checksum OxXX = This byte should be programmed 
such that a one-byte checksum (add all bytes 


together) of the entire 128 byte block equals 
Ox00. 


7.3.3 CTA Extension Version 3 


Version 3 includes all of the capabilities of Versions 1 & 2, but also includes the ability to specify 
any of the CE Video Formats using “CTA Short Video Descriptors.” It provides the ability for the 
Sink to specify what types of advanced audio it supports using “CTA Short Audio Descriptors.” It 
also provides a way for the Sink to specify its speaker configuration. This information is 
complementary to the speaker channel allocation information that is sent in the Audio 
InfoFrame. 


If more than one CTA Extension is needed, the value of byte 3 shall be the same in all 
extensions. 


CTA Extension Version 3 is shown in Table 58. 
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Table 58 - CTA Extension Version 3 


[—syte# | Value |Description —*+Y| Sma SSSCSC~S~S 
0 | 0x02 | Tag (On0D tS 
[1 [0x03 [Revision umber ——SS—siSOSOSCSCSSCSC“‘SsSC‘“‘~s~s~s*s~S 


Byte number offset d where 18-byte | d= offset for the byte following the data block 

descriptors begin (typically Detailed collection. If no data is provided in the data block 

Timing Descriptors) collection, then d=4. If d=0, then no detailed timing 
descriptors are provided, and no data is provided in the 
data block collection. 


3 Total number of Detailed Timing bit 7 (CTAX_UNDERSCAN) = 1 if Sink underscans IT 

Descriptors describing Native Video Video Formats by default. 

Formats in entire E-EDID structure. bit 6 (CTAX_BASIC_ AUDIO) = 1 if Sink supports Basic 

Also, indication of underscan Audio. 

support, audio support, and support bit 5 (CTAX_YCC444) = 1 if Sink supports YCgCp 4:4:4 in 

of YCgCp is included addition to RGB. 
bit 4 (CTAX_YCC422) = 1 if Sink supports YCgCp 4:2:2 in 
addition to RGB. 
bits 3-0 (CTAX_NATIVE_DTDS) = total number of native 
DTDs (see Section 2.2 for definition of "Native Video 
Format”). 

a ee 


Start of data block collection CTA Data Block Collection (see Section 7.4). 


End of data block collection 


Start of 18-byte detailed timing See Section 3.10.2 of VESA E-EDID Standard [9] 
d+(18*n)-1 End of 18-byte detailed timing 
descriptors where n is the number of 
| descriptors included 
aera) __1 2 Beginning of Pate 


127 Checksum This byte should be programmed such that a one-byte 
checksum (add all bytes together) of the entire 128 
byte block equals 0x00. 


CTAX_NATIVE_DTDS indicates the total number of 18-byte DTDs defining Native Video Formats 
in Block O and the CTA Extensions (see Section 2.2 for definition of "Native Video Format"). The 
placement of native 18-byte DTDs shall be contiguous, starting with the first DTD in the DTD list 
(which starts in EDID Block 0). Value zero means that this information is not provided (for 
backward compatibility with prior implementations), or that the display does not support 
reception of a Native Video Format, or that the Native Video Format cannot be represented as 
an 18-byte DTD. If a Native Video Format is present, the Source may determine additional 
Native Video Formats in the EDID by matching the resolution to the other formats with 
different frame rates. 


A DTV that declares it is capable of displaying Pictures formatted in either YCgCr chroma 
sampling format (i.e., 4:2:2 or 4:4:4) shall be capable of displaying Pictures encoded in either 
SMPTE ST 170 [1] color space or Rec. ITU-R BT.709 [7] color space. DTVs capable of displaying 
Pictures encoded in other color spaces may declare support for these color spaces ina 
Colorimetry Block stored in their EDID. The format of the Colorimetry Data Block is defined in 
Section 7.5.5. 
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In order to ensure YCgCr interoperability between any two YCgCpe-capable devices, a Sink that 
supports either type of YCgCr Pixel Data (4:2:2 or 4:4:4) should support both types and 
therefore would set both bits 4 and 5 of byte 3. 


Note: The HDMI specification requires this behavior. 
A Sink that does not support YCgCr Pixel Data shall have both bits 4 and 5 clear. 


If the Sink supports any type of digital audio on this interface, then it shall also support Basic 
Audio and shall indicate this by setting the Basic Audio bit (bit 6). 


Bit 7 of byte 3 shall be set if the Sink underscans IT Video Formats by default. 
7.4 CTA Data Block Collection 


A CTA Data Block Collection is a sequence of Data Blocks. A Data Block consists of a header and 
a payload, see Table 59. The header of a Data Block consists of one byte, with the most 
significant three bits of the header used for the CTA Tag Code designating the format of the 
payload, and the least significant five bits used for the length field indicating the number of 
bytes of the payload. The list of CTA Tag Codes is shown in Table 60. 


In the case of a Video Data Block or an Audio Data Block, the payload consists of one or more 
Descriptors. For other data block types, the payload format may be different or include an CTA 
Extended Tag Code byte (see below). However, the length is always the number of bytes 
following the header byte. 


Table 59 - Data Block 


pbytew | 7 | 6 | 5 | 4] 3s | 2 ft ft 
Length (L) of following data block payload (in bytes) 


First Payload Byte 
Second Payload Byte 


Last of L Payload Bytes 


Table 60 - CTA Tag Codes 


CTA Tag Code 
Type of Data Block 


Audio Data Block (includes one or more Short Audio Descriptors) 
Video Data Block (includes one or more Short Video Descriptors) 


Speaker Allocation Data Block 


VESA Display Transfer Characteristic Data Block [134] 


Use Extended Tag 


Vendor-Specific Data Block 
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If the CTA Tag Code is 7 (Use Extended Tag) then the second byte of the data block contains the 
CTA Extended Tag Code, which indicates the actual type of the data block, see Table 61. For 
backwards compatibility, the Length field in the first byte does include the second byte, which 
contains the CTA Extended Tag Code. The list of CTA Extended Tag Codes is shown in Table 62. 


Note that data blocks with CTA Tag Codes of 1 through 6 are limited to containing 31 payload 
bytes whereas those with CTA Extended Tag Codes are limited to 30 payload bytes. 


Table 61 - Extended Tag Data Block 


ee 
CTA Tag Code (0x07) Length (L) of following data block payload (in bytes) 
CTA Extended Tag Code 


First Payload Byte 
Second Payload Byte 


L+1 Last of L-1 Payload Bytes 
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Table 62 - CTA Extended Tag Codes 


oe see Tag Type of Data Block 
Video Capability Data Block 
Vendor-Specific Video Data Block 
VESA Display Device Data Block [135] 
Reserved for VESA Video Data Block 
Reserved for HDMI Video Data Block [140] 
Colorimetry Data Block 
DR Static Metadata Data Block 
DR Dynamic Metadata Data Block 
Reserved for video-related blocks 
Video Format Preference Data Block 
4:2:0 Video Data Block 
YCgCr 4:2:0 Capability Map Data Block 
Reserved for CTA Miscellaneous Audio Fields (MAF) 
Vendor-Specific Audio Data Block 
HDMI Audio Data Block [140] 
Room Configuration Data Block 
Speaker Location Data Block 
Reserved for audio-related blocks 
InfoFrame Data Block (includes one or more Short InfoFrame Descriptors) 


as 
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DisplaylD Type VII Video Timing Data Block 
DisplaylD Type VIII Video Timing Data Block 


eS) 
Ui 


36..41 


AS 
NO 


DisplaylD Type X Video Timing Data Block 
43...119 
12 
121 
122...127 
128...255 


oO 


HDMI Forum EDID Extension Override Data Block [140] 
HDMI Forum Sink Capability Data Block [140] 

Reserved for HDMI 

Reserved 


The CTA Data Block Collection shall conform to the format shown in the example in Table 63. 
The order of the Data Blocks is not constrained. It is also possible to have more than one of a 
specific type of data block if necessary to include all of the descriptors needed to describe the 
Sink’s capabilities. Section 7.6 details which data blocks may have multiple instances and which 
may not. 


These data structures may grow in the future and so the Source shall continue to parse the 
known (currently specified) fields in a data block even if the length is longer than currently 
specified. 
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Table 63 - Example of a CTA Data Block Collection 


Code (L1) 
Video Data 
Block 
pa a 
Code (L>) 
CTA Short Audio Descriptor 1 
Audio Data 
a 
CTA Short Audio Descriptor L2/3 
Speaker length=total number of speaker allocation bytes 
Allocation following this byte (L3=3) 
epeancr Tag Code 
Allocation 
DaEaBleck Speaker Allocation Data Block Payload (3 bytes) 
Vendor- length=total number of Vendor-Specific bytes following 
Specific Tag this byte (L4) 
Code 
ee 
es 
i. 
le 
Video 
Capability hake Tag oe et) 
Data Block Video Capabilities Ext. Tag Code = 00h 
Video Capabilities Data Byte 3 (see Section 7.5.6) 


Any data block with a CTA Extended Tag Code in the 0 to 15 range indicates strictly video- 
related characteristics of the display. Any repeater device that re-transmits a video stream from 
a Source to a Sink without any modification of the Video Timing or video data or video-related 
InfoFrame(s) shall also pass every such data block upstream, that is, the repeater shall copy the 
contents of the data block(s) from the downstream Sink’s EDID to the repeater’s own upstream 
EDID. 


Any data block with a CTA Extended Tag Code in the 16 to 31 range indicates strictly audio- 
related characteristics of the display. Any repeater device that re-transmits an audio stream 
from a Source to a Sink without any modification of the audio timing or audio data or audio- 
related InfoFrame(s) shall also pass every such data block upstream, that is, the repeater shall 
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copy the contents of the data block(s) from the downstream Sink’s EDID to the repeater’s own 
upstream EDID. 


Repeaters shall not copy the contents of any other data block from a downstream EDID to their 
own upstream EDID unless the characteristics of the Sink indicated by that data block are 
known to be also true for the repeater device or the combination of the repeater and 
downstream device. This also applies to the original Vendor-Specific Data Block (CTA Tag Code = 
3); if the repeater does not recognize the vendor ID or does not understand the entire contents 
of that block, it shall not be copied into the repeater’s EDID. 


When a Version 3 CTA Extension is provided in the Sink’s EDID data structure, a Short Video 
Descriptor (SVD) shall be provided for each CTA Video Format supported by the Sink. SVDs shall 
be listed using one (or more) Video Data Blocks (see Section 7.5.1) and/or YCgCr 4:2:0 Video 
Data Blocks (see Section 7.5.10). 


If the Sink supports YCgCpe 4:2:0 sampling capability, then a YCgCr 4:2:0 Video Data Block 
(Y420VDB, see Section 7.5.10), a YCgCr 4:2:0 Capability Map Data Block (Y420CMDB, see Section 
7.5.11), or a DisplayID VTDB (see Section 7.5.17) shall be included in the CTA Extension. Source 
devices shall not transmit a Video Format in YCgCr 4:2:0 sampling mode to a Sink device unless 
support for YCgCr 4:2:0 mode is indicated in a Y420VDB, Y420CMDB, or a VTDB for that Video 
Format. 


7.5 CTA Data Blocks 
Data Blocks defined by CTA are described in the following Sections. 
7.5.1 Video Data Block 


A Video Data Block (VDB) lists Video Formats supported by the Sink. Each supported Video 
Format is represented by a Short Video Descriptor (SVD) containing a Video Identification Code 
(VIC) and, in the case of VICs 1 through 64, a Native Video Format indicator. 


For VICs 1 through 64, the format of the Short Video Descriptor shall conform to that shown in 
Table 64. The lower 7-bits are an index associated with the Video Format supported. The most 
significant bit declares whether the format is a Native Video Format of the display (native =1, 
not native = 0). Typically, there is a single SVD, with its native bit set. Sources should not 
necessarily convert Video Formats to a Native Video Format, but should follow 
recommendations for using Source Pass-through Mode and preferred timing (see Section 
7.2.2). 


Table 64 - Short Video Descriptor (for codes 1 through 64) 


iS 
peytes | o7 | 6 | os | 4 7 3 | 2 ft 


Video Identification Code 
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For VICs 65 through 127 and 193 through 255, the format of the SVD shall conform to that 


shown in Table 65. In this case, all 8-bits are an index associated with the format supported and 
Native Video Formats are communicated via other means. 


Table 65 - Short Video Descriptor (for codes 65 through 127 and 193 through 255) 


nS 
peyte# | 7 | o6 | os 7 4] 3 |} 2 fot | oe 


aa Video Identification Code 


The indexes are the same as those used in the AVI InfoFrame and are shown in Table 3. 
Ordering of SVDs within a VDB is not important as format preference relies on the VFPDB 


(Section 7.5.12). Legacy Sources not supporting the VFPDB, or if the VFPDB is not present, may 
rely on the first SVD as a preferred Video Format. 


The Source shall interpret SVD codes according to the following pseudo code: 
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If SVD == 0 then 
Reserved 
Elseif SVD >= 1 and SVD <= 64 then 
7-bit VIC is defined (7-LSB’s) and NOT a native code 
Elseif SVD >= 65 and SVD <= 127 then 
8-bit VIC is defined (from first new set) 
Elseif SVD == 128 then 
Reserved 
Elseif SVD >= 129 and SVD <= 192 then 
7-bit VIC is defined (7-LSB’s) and IS a native code 
Elseif SVD >= 193 and SVD <= 253 then 
8-bit VIC is defined (from second new set) 
Elseif SVD == 254 then 
Reserved 
Elseif SVD == 255 then 
Reserved 
End if 


Sinks shall not use any reserved values for SVDs in the VDB. 
7.5.2 Audio Data Block 


If audio is supported in the Sink, as indicated by the Basic Audio support bit in the Version 3 CTA 
EDID Descriptor, then CTA short audio descriptors shall be used to declare which (if any) audio 
formats are supported in addition to Basic Audio. If only Basic Audio is supported, no Short 
Audio Descriptors are necessary. 


The Short Audio Descriptor shall conform to the formats given in Table 66 through Table 71 as a 
function of the Audio Format Code. Several types of audio may be supported, but each one 
Shall be listed in its own short audio descriptor with its designated code and the associated 
information. The list of Audio Format Code values is given in Table 37 and Table 39. 


Each Short Audio Descriptor is 3-bytes long. There can be up to 31 bytes of payload in a Data 
Block, therefore there may be up to 10 Short Audio Descriptors in the Audio Data Block (ADB). 


The format of the second and third bytes is determined by the Audio Format Code contained in 
the first byte as shown in Table 66 through Table 75. One format code is used for 
Uncompressed Audio (i.e., L-PCM), and the others are used for Compressed Audio (e.g., AC-3, 
MPEG2, DTS, etc.). For some compressed formats, byte 3 is further defined in other format- 
specific documents. 
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Table 66 - CTA Short Audio Descriptor for Audio Format Code 1 (L-PCM) 


a 
ppytes | 7 | 6 | 5 | 4 7 3 | 2 | 1a fo 


F17=0 Audio Format Code = 0001 Max Number of channels - 1 
| 2 «| sF27=0 192 kHz 176.4 kHz 96kHz | 88.2 kHz 48 kHz | 44.1 kHz 32 kHz 
_ 3 Oe eS F35=0 F34-0 | _F33=0 


Table 67 - CTA Short Audio Descriptor for Audio Format Codes 2 to 8 


a 
ppyte# | 7 | 6 | 5 | 4 ] 3 | 2 | 1 fo 
| 2 | F270 | 192kHz | 176.4kHz | 96kH2 | 88.2kHz | 48kHz | 44.1kKH2 | 32kKHz 
_ 3 


Maximum bit rate divided by 8 kHz 


Table 68 - CTA Short Audio Descriptor for Audio Format Codes 9 to 13 


eas 
peyte# | 7 | 6 | 5 |] 4 | 3 | 2 | 1 | oo 
| 2 | F270 | 192kHz | 176.4kHz | 96kHz | 88.2kHz | 48kHz | 44.1kHz | 32kHz 
zz 


Audio Format Code dependent value. 


Table 69 - CTA Short Audio Descriptor for Audio Format Code 14 (WMA Pro) 


a © 
pbyte# | 7 | 6 | 5 |] 4 | 3 | 2 | 1 | 0 | 


F17=0 Audio Format Code=1110 Max Number of channels - 1 
| 2) «| F27=0 | 192kHz | 176.4kHz | 96kHz | 88.2kHz | 48kHz | 44.1 kHz 32 kHz 
| 3__| _F37=0 | _F36=0 F35=0 F34=0 F33=0 


When the Audio Format Code bit-field in Data Byte 1 of a CTA Short Audio Descriptor is set to 
15, it shall conform to the formats given in in the Tables below as a function of the Audio 
Coding Extension Type Code. 


The Audio Format Code Extension contained in the third byte, as shown in Table 70 and Table 
71, determines the format of the third byte. For some compressed formats, byte 3 is further 
defined in other format-specific documents. 
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Table 70 - CTA Short Audio Descriptor for Audio Coding Extension Type Codes 4 to 6 


et ee 
peytes | 7 | 6 | 5 | 4 ] 3 | 2 | a | 


F17=0 Audio Format Code=1111 Max Number of channels - 1 
| 2 | F27=0 | F26=0 F25=0 96 kHz | 88.2 kHz 48 kHz 44.1 kHz 32 kHz 
= oe Audio Coding Extension Type Code 1024 TL 960_TL 22.2ch SysH 


For audio format extension type code value 6 (decimal), bit O of Data Byte 3 (see Table 70) is 
used to indicate support for 22.2 multichannel sound. If Rec. ITU-R BS.2051 [139] System H 22.2 
multichannel sound is supported, bit O shall be set to 1. For audio format extension type code 
values 4 & 5 (decimal), bit O of Data Byte 3 (see Table 70) is not used and shall be set to zero. 


For audio format extension type code values 4, 5, 6, 8 & 10 (decimal), bits 1 and 2 of Data Byte 
3 (see Table 70 and Table 71) are used to indicate support for different AAC audio frame 
lengths. If an AAC frame length of 960 samples is supported, bit 1 shall be set to 1. If an AAC 
frame length of 1024 sample is supported, bit 2 shall be set to 1. 


Table 71 - CTA Short Audio Descriptor for Audio Extension Type Codes 8 and 10 


en *~ 
pBytede | ie a 


F17=0 Audio Format Code=1111 Max Number of channels - 1 
| 2 «|s«F27=0 F26=0 F25=0 96 kHz | 88.2 kHz 48 kHz 44.1 kHz 32 kHz 
a ae Audio Coding Extension Type Code 1024 TL 960_TL MPS_L 


MPEG Surround (MPS) data may be present in MPEG-4 AAC bit streams. When present, MPS 
provides a significant increase of audio compression efficiency. Spatial audio data can be 
conveyed in the AAC extension_payload() mechanism using extension_type EXT_SAC DATA or 
as a second layer in the PayloadMux(), as defined by ISO/IEC 14496-3 [25]. The presence of MPS 
data can be signaled either implicitly or explicitly. With implicit signaling, the mere presence of 
the EXT_SAC_DATA extension elements in the bit stream implies that MPS data is present. With 
explicit signaling, the presence of MPS data is signaled by means of the audio object type (AOT) 
MPEG Surround (30) in the AudioSpecificConfig() data, which permits the conveyance of 
configuration data specific to the MPS decoder [25]. 


For audio format extension type code values 8 and 10 (decimal), bit O of Data Byte 3 (see Table 
71) is used to indicate whether the Sink supports implicit or both implicit and explicit signaling 
of MPEG Surround data. If the bit 0 is set to 0, then the Sink supports only implicitly signaled 
MPEG Surround data. If bit 0 is set to 1, then the Sink supports both implicitly and explicitly 
signaled MPEG Surround data. 


It is strongly recommended that, if a Sink indicates support for core audio stream coding type 
(e.g., MPEG-4 HE AAC), then the Sink should be able to receive MPEG Surround (e.g., MPEG-4 
HE AAC + MPEG Surround) and be able to decode the core audio stream and ignore the MPEG 
Surround extension in the bit stream. Also, it is strongly recommended that Source devices 
should not refuse transmission of an implicitly signaled MPEG Surround-encoded audio stream 
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if the Sink device indicates support for the core audio stream coding type, but does not indicate 
support for the core audio stream in conjunction with MPEG Surround. 


Table 72 - CTA Short Audio Descriptor for Audio Extension Type Code 11 (MPEG-H 3D Audio) 


a 
Peyte# | 7 | 6 | 5 | 4 | 3 | 2 fot fe 


F17=0 Audio Format Code=1111 MPEG-H 3D Audio Level 
| 2 | F27=0 | 192 kHz 176.4 kHz 96 kHz | 88.2 kHz 48 kHz 44.1 kHz 32 kHz 
a Audio Coding Extension Type Code=0x0B F32=0 | BP TLS 


Table 73 - MPEG-H 3D Audio Level 


-2 [1 jo 


po | o}ot Unspecified | 
Reserved 


For audio format extension type code value 11 (decimal), bits 2, 1, and 0 of Data Byte 1 (see 
Table 72) are used to indicate the maximal supported MPEG-H 3D Audio level as defined in 


Table 73. Bit O of Data Byte 3 is used to indicate support for the MPEG-H 3D Audio Low 
Complexity Profile. Bit 1 of Data Byte 3 is used to indicate support for the MPEG-H 3D Audio 
Baseline Profile. 


Table 74 - CTA Short Audio Descriptor for Audio Extension Type Code 12 (AC-4) 


a © 
peyte# | 7 | 6 | 5 |] 4 | 3 | 2 ft 
| 4 | Fi7-0 | Audio FormatCode=1111 | F120 | Fd=0 | F10-0 
| 2 | F270 | 192kHz | F25-0 | 96kHz | F23-0 | 48kHz | 44.1kHz | F20-0 | 
_ 3 | Audio Coding Extension Type Code=0x0C__|__ Audio Format Code dependent value_| 


Table 75 - CTA Short Audio Descriptor for Audio Extension Type Code 13 (L-PCM 3D Audio) 


«| 
(eye | 7 | 6 | 5 |] 4 | 3 | 2 | oa fo | 


ae Audio Format Code=1111 
| 2 | MC4 | 192 kHz 176.4 kHz 96 kHz | 88.2 kHz 48 kHz 44.1 kHz 32 kHz 


ea Audio Coding Extension Type Code=0x0D 


121 


CTA-861-H 


For Audio Coding Extension Type OxO0D (L-PCM 3D Audio), bits MC4:MCO of bytes 1 and 2 
indicate Max Number of Channels -1. 


The Audio Format Codes used in each Short Audio Descriptor shall be as defined for CTO-CT3 in 
Table 37 except that the value zero shall be reserved and shall not be used. The Audio Coding 
Extension Type Codes shall be as defined for CXTO-CXT4 in Table 39. 


7.5.3 Speaker Allocation Data Block 


If the Sink supports multi-channel uncompressed digital audio as indicated in the Audio Data 
Block, then the Speaker Allocation Data Block (SADB) shall be included in the CTA Extension. It 
is recommended that the Sink include a valid Speaker Allocation Data Block if it supports any 
type of digital audio (including Basic Audio), but this is not required. 


The SADB is shown in Table 76. The Sink signifies that a speaker, or pair of speakers, is present 
by setting the bit associated with that speaker or pair of speakers to one. The speaker 
designations are the same as is used in the Audio InfoFrame (see Figure 6 and Table 40). In 
many cases, a single flag represents a channel pair (2 channels). Using the Speaker Allocation 
Data Block, these paired configurations cannot be represented independently. If independent 
representation of these channels is desired, then all channels must be represented with a 
Speaker Location Descriptor which is contained in a Speaker Location Data Block, (see Section 
7.5.16). 


Table 76 - Speaker Allocation Data Block (SADB)?° 


ee 
ra ram tenon amine 


CTA Tag Code (0x04) Length of following data block (in bytes) (0x03) 


TpSiL/ tie TpFL/ 
pa F37=0 F36=0 F35=0 F34=0 F33=022 | BtFL/ BtFR ie 


20 Note that some speaker names have changed from CTA-861-F to CTA-861-G. See Annex Q for details. 


21 Use of F16 for RLC/RRC has been deprecated. RLC/RRC are considered to be logically the same speaker positions as BL/BC. 
Legacy Sinks might use RLC/RRC instead of BL/BR; Sources shall route audio intended for RLC/RRC to BL/BR. See Table 35 and 
Table 41. Future use of F16 for other speaker positions is reserved. 


22 Use of F33 for TpLS/TpRS has been deprecated. Future use of F33 for other speaker positions is reserved. 
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7.5.4 Vendor-Specific Data Block 


The content of the Vendor-Specific Data Block is defined in Table 77. A Sink may contain one or 
more Vendor-Specific Data Blocks (VSDB) to indicate proprietary information that may be of 
interest to the vendor's own Sources. 


The VSDB shall contain the 3 bytes of the IEEE OUI as well as any additional payload bytes 
needed. 


Note: HDMI Sinks use one version of the VSDB to indicate HDMl-specific characteristics 
of the Sink. Additional VSDBs, such as those with the vendor's own IEEE OUI, may also 
be included in the E-EDID. 


Table 77 - Vendor-Specific Data Block (VSDB) 


es +: 
_sytes | 7 | 6 | 5 | 4 | 3 | 2 fa 
poe EEE OUI third twohexdigits 
(ome at 
| a 


IEEE OUI second two hex digits 
IEEE OUI first two hex digits 


5 
Vendor-Specific Data Block Payload (L-3 bytes) 
L+1 


7.5.5 Colorimetry Data Block 


The Colorimetry Data Block (CDB) indicates support of specific extended colorimetry standards 
and gamut-related as yet, undefined metadata. Details regarding the contents of the CDB are 
provided in Table 78, Table 79 and 


Table 80. 


Byte 3 and bits 6 through 7 of Byte 4 are allocated for Colorimetry data. The definitions of the 
colorimetry flags are shown in Table 79. Setting a colorimetry flag to one shall indicate that the 
Sink is capable of displaying Pictures encoded in that colorimetry. Byte 4, bits O through 3 are 
listed in 


Table 80 and designated for future gamut-related metadata. As yet undefined, this metadata is 
carried in an interface-specific way. 


If the colorimetry flag for ST2113pep is set to one, the Sink shall understand two types of P3 
colorimetry based on SMPTE ST 2113: P3D65 and P3DCI. If the colorimetry flag for ICrtCp is set to 
one, the Sink shall also indicate support for the PQ Transfer Function, or the HLG Transfer 
Function, or both, in an HDR Static Metadata Data Block. (Support for PQ is indicated with the 
TF_2 flag, and HLG support is indicated with the TF_3 flag. See Section 7.5.13.) 
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Table 78 - Colorimetry Data Block (CDB) 


es +, ee 
[etew| 7 | 6 | 5 | 4 | 3 {| 2 { 1 { o 
rength of following data block (in bytes) (Gx03) 
2 


CTA Extended Tag Code (0x05) 


| 3 | BT2020ncs | BT2020vec | BT2020evec | opRGB_| opYCCéo1 
4 {ST2113:60°3] _ICrCe_ | F45=0__ | FA4=0 


Table 79 - Data Byte 3 Colorimetry Support Flags 


po Flag Colorimetry 


BT 2020cycc Colorimetry based on Rec. ITU-R BT.2020 [40] Y’CC’ gcC’ rc 


) 


Table 80 - Data Byte 4 Colorimetry Metadata Support Flags 


Future metadata profile 


Future metadata profile 
Future metadata profile 
Future metadata profile 


7.5.6 Video Capability Data Block 


The Video Capability Data Block (VCDB) allows a display to declare default, fixed, or InfoFrame- 
controlled overscan/underscan and Quantization Range (see Table 81). Separate 
overscan/underscan handling capabilities may be declared for Preferred, IT, and CE Video 
Format categories. 


Note: Future revisions of CTA-861 may provide additional bytes to the VCDB payload. 
Source devices shall use the Length field to determine payload length and should ignore 
additional bytes (when present) beyond the given length of the VCDB. 


23 This flag was referred to as DCI-P3 in CTA-861-G and earlier. 
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es eee eee 
ppyte# | 7 | 6 | 5 | 4 | 3 | 2 fa | o 


CTA Tag Code (0x07) Length of following data block (in bytes) (0x02) 


CTA Extended Tag Code (0x00) 


eee! 
3 tf o | as js} spro} simi | sito | scer_ | siceo_ 


YCC Quantization Range 
Selectable 


fo] toe 


Selectable 
(via AVI YQ) 


Table 82 - Video Capability Descriptor Data Byte 3 


RGB Quantization Range 
Selectable 


a] tea 


Selectable 
(via AVI Q) 


PT Overscan/ 
underscan 
behavior 
(Applies to the 
Preferred Video 
Format) 


No Data (refer 
toS CEorS IT 
fields) 


Overscanned 


Underscanned 


Supports both 
over- and 
underscan 


IT Overscan/ 
underscan 
behavior 
(Applies to IT 
Video Formats) 


IT Video 
Formats not 
supported 


Always 
Overscanned 


Always 
Underscanned 


Supports both 
over- and 
underscan 


CE Overscan/ 
underscan 
behavior 
(Applies to CE 
Video Formats) 


CE Video Formats 
not supported 


Always 
Overscanned 


Always 
Underscanned 


Supports both 
over- and 
underscan 


Displays do not always present the entire incoming Picture to the viewer. Sometimes displays 
overscan the incoming Video Format such that pixels along the periphery of the Picture are 
masked (occluded). For example, a display may purposely mask a portion of the Picture to hide 
distracting content (received from a Source) or the unsightly edges of a raster. In either case, 
what the viewer sees is either an underscanned or overscanned visible picture, which may 
either include (in the case of underscanning) the whole incoming Picture or (in the case of 
overscanning) a somewhat occluded visible Picture. 


CE application specific displays (e.g., DTVs) typically overscan all Video Formats, while IT 
application specific displays (e.g., computer displays) typically underscan all Video Formats. 
Multipurpose displays typically adapt to the incoming signal by either overscanning or 
underscanning depending on the type of Video Format received. The S_CE,S_IT, andS_ PT 
values allow a display to formally declare its overscan/underscan options by CE, IT, and 
Preferred Video Format category (see Table 82). 
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Each of the three S_ xx fields indicate whether the display, for all Video Formats in that 
category, always overscan those Video Formats, always underscan those formats or support 
both overscanning and underscanning of those formats. Indications shall be accurate for all 
Video Format categories — so long as the VCDB is present in the EDID. If the display does not 
support the reception of one of the two main Video Format categories (CE and IT), then the 
indication for the unsupported category shall be set to OO. 


The display’s Preferred Video Format may be either a CE or an IT Video Format but may have 
different overscan/underscan behavior than the rest of the CE or IT Video Formats supported 
by the display. If the display declares a non-zero value for the S_PT (preferred timing 
overscan/underscan behavior) field, and the Source outputs that Video Format, then the S_ PT 
declaration shall take precedence over both S_CE and S _IT declarations. If the S_PT field is O 
then the overscan/underscan behavior of this format is indicated by either the S CE or S_IT 
fields, depending on whether the Preferred Video Format is a CE or IT Video Format. 


If the display declares that it can support both overscan and underscan for a Video Format 
category and the Source outputs that type, then the display shall either automatically overscan 
or underscan (in response to the AVI InfoFrame S field) or provide user options of selecting an 
overscan or an underscan mode. If operating in an automatic mode, the display shall overscan 
the incoming Picture if it receives AVI S=1 and it shall underscan if it receives AVI S=2. The 
Source shall always set the AVI S field correctly if that information is known by the Source. If the 
display receives no AVI or AVI S=0, then the display should overscan CE Video Formats and 
underscan IT Video Formats by default but may provide a user-selectable alternative behavior. 


If the display does not provide the VCDB then the Source should assume that CE Video Formats 
are overscanned by the display and that IT Video Format behavior is indicated by CTA Extension 
byte 3 bit 7 (underscan). If underscan=1 then the Source should assume that IT Video Formats 
are underscanned and if underscan=0, that IT Video Formats are overscanned. 


If the Source outputs a Video Format that can be underscanned by the display, then the Source 
may safely place essential content at the very edge of the signaled Picture and the display shall 
ensure that the entire signaled Picture is visible. 


When outputting a Video Format that is always overscanned by the display, IT Sources (which 
normally render interactive menus and window controls along the periphery of the transmitted 
Picture) should confine essential content to a smaller area of the signaled Picture — to ensure 
the viewer operability. Media-centric Sources, on the other hand, which fill the signaled Picture 
with (decompressed) broadcast or prerecorded content — precomposed for an overscanned 
display, should simply pass-through such content without further processing (see Source Pass- 
through Mode, Section 7.2.2). 


The exact dimensions of the overscanned visible picture may vary and are not specified in CTA- 
861. 


CTA-861 supports both Limited and Full Quantization Ranges (see Section 5.4). In order to 
ensure reliable interoperability with Sources, the Sink shall set the RGB Quantization Range 
Selectable QS bit to 1. Setting QS to 0 is deprecated and shall not be used in new designs for 
Sinks. By setting QS to 1, Sources can override the default Quantization Range for any Video 
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Format. The Sink shall expect Limited Range pixel values if it receives Q=1 in the AVI InfoFrame 
and it shall expect Full Range pixel values if it receives Q=2 (see Section 6.4.3 for information 
concerning bits Q1 and QO). For other values of Q, the Sink shall follow the Default Quantization 
Range as per Table 5. 


If the Sink does not support YCbCr color formats, then it shall set the YCC Quantization Range 
Selectable QY bit to O. 


If the Sink supports YCbCr color formats, then it shall set the YCC Quantization Range Selectable 
QY bit to 1. Setting QY to 0 when YCbCr color formats are supported is deprecated and shall 
not be used in new designs for Sinks. By setting QY to 1, Sources can override the default 
Quantization Range for any Video Format. The Sink shall expect Full Range pixel values if it 
receives YQ=1 in the AVI InfoFrame and it shall expect Limited Range pixel values if it receives 
YQ=0 (see Section 6.4.3 for information concerning bits YQ1 and YQO). For other values of YQ, 
the Sink shall follow the Default Quantization Range as per Table 5. 


In previous CTA-861 versions these Quantization Range Selectable bits were allowed to be O, in 
which case the Sink would fall back to the default Quantization Range (see Table 5). In practice, 
however, many Sources (in particular those of non-CE applications) ignored these default 
Quantization Range rules and used a different Quantization Range. By allowing Sources to 
explicitly signal which Quantization Range is used, interoperability with such Sources should 
improve. 


7.5. Vendor-Specific Video Data Block 


The Vendor-Specific Video Data Block (VSVDB) allows a display to declare up to 27-bytes of 
vendor-defined video capabilities-related data (see Table 83). A Sink may contain one or more 
VSVDBs to indicate proprietary information that may be of interest to the vendor's own 
Sources. The VSVDB shall contain the 3 bytes of the vendor's IEEE OUI as well as any additional 
payload bytes needed. 
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Table 83 - Vendor-Specific Video Data Block (VSVDB) 


SS eae 
[byte# | 7 | 6 | 5 | 4 | 3 | 2 | 1 
| 1 = | CTATagCode (0x07) Length (L) = number of bytes following this byte 
pp 2 | TAM Extended Tag Code (0x01) 
p38 | EEE OUI thirdtwohexdigits 
4 i 
oe 


IEEE OUI second two hex digits 


IEEE OUI first two hex digits 


6 
Vendor-Specific Video Data Block Payload (L-4 bytes) 
L+1 


7.5.8 Vendor-Specific Audio Data Block 


The Vendor-Specific Audio Data Block (VSADB) allows a display to declare up to 27-bytes of 
vendor-defined audio capabilities-related data (see Table 84). A Sink may contain one or more 
VSADBs to indicate proprietary information that may be of interest to the vendor's own 
Sources. The VSADB shall contain the 3 bytes of the vendor's IEEE OUI as well as any additional 
payload bytes needed. 


Table 84 - Vendor-Specific Audio Data Block (VSADB) 


ee 
7 | 6 | os | 4 ft 3 | 
Length (L) = number of bytes following this byte 
Pp o2 | CTA Extended Tag Code (Ox) 
P38 | EEE OUI thirdtwohexdigits 
i a i 
| 5 


IEEE OUI second two hex digits 


IEEE OUI first two hex digits 


6 
Vendor-Specific Audio Data Block Payload (L-4 bytes) 
L+1 


7.5.9 InfoFrame Data Block 
An InfoFrame Data Block (IFDB) may be used to declare the number of additional Vendor- 


Specific InfoFrame (VSIFs) that can be received simultaneously, and optionally, support for 
particular InfoFrames and their relative priority (see Table 85 and example in Annex A.2.20). 
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Table 85 - InfoFrame Data Block (IFDB) 


ee ee 
_sytes | 7 | 6 | 5 | 4 | 3 | 2 {1 | 


1 CTA Tag Code (0x07) Length (La) = # of bytes following this byte 
CTA Extended Tag Code (0x20) 


3 
through InfoFrame Processing Descriptor 
Lp+4 


Lp+5 (optional) Short InfoFrame Descriptor(s) 


through 
L ri (optional) Short Vendor-specific InfoFrame Descriptor(s) 
a 


The IFDB shall begin with a Data Block Header Byte (see Table 59) with Tag Code 0x07 and 
Length equal to the total number of bytes comprising the IFDB minus one. The Data Block 
Header Byte shall be immediately followed by an InfoFrame Data Block Extension Tag with code 
0x20, which identifies the Data Block as being an IFDB. 


An InfoFrame Processing Descriptor shall immediately follow the InfoFrame Data Block 
Extension Tag. 


This InfoFrame Processing Descriptor shall begin with an InfoFrame Processing Descriptor 
Header as shown in Table 86. 


Table 86 - InfoFrame Processing Descriptor Header 


ESESEAESESDEDESED 


Payload Length (Lp) = # of bytes F14=0 F13=0 F12=0 F11=0 F10=0 
following the next byte 


Number of additional VSIFs that can be received simultaneously 


The Payload Length field of the InfoFrame Processing Descriptor Header indicates the number 
of extension bytes (if any), in the InfoFrame Processing Descriptor, that follow Byte 2 of its 
Header. The InfoFrame Processing Descriptor shall have a Payload Length of zero bytes. 


Note: Future revisions of CTA-861 may provide extended InfoFrame Processing 
Descriptor payload by setting the Payload Length field to a non-zero value. Therefore, 
Source devices shall use the Payload Length field of the InfoFrame Processing Descriptor 
Header when locating the beginning of other structures following the InfoFrame 
Processing Descriptor. 


Byte 2 of the InfoFrame Processing Descriptor Header shall be set equal to the number of 
additional VSIFs that can be received in addition to the first. If the Sink is only capable of 
receiving a single VSIF, then Byte 2 shall be set to zero. 


A list of declared InfoFrames may follow the InfoFrame Processing Descriptor. This list may be 
incomplete. When used to declare supported InfoFrames, declared InfoFrame types shall be 
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listed using Short InfoFrame Descriptors (SIDs). The format of SIDs shall conform to one of two 
different structures — depending on the InfoFrame Type Code given in bits 0 through 4 of Byte 
1. Vendor-Specific InfoFrames (InfoFrame type code 0x01) shall be declared using the format 
shown in Table 88, while all other InfoFrames types shall be declared using the format shown in 
Table 87. The InfoFrame type codes shall be the same as those listed in Table 7. Like the 
InfoFrame Processing Descriptor, SIDs shall have a Payload Length of zero bytes unless 
otherwise specified. The Payload Length of a Short Vendor-Specific InfoFrame Descriptor 
(shown in Table 88) refers to the number of additional bytes following the required 3-byte OUI 
and shall be set to zero unless the vendor specifies additional payload bytes beyond the 24-bit 
IEEE Registration Identifier bytes. The Payload Length of a Short InfoFrame Descriptor (shown in 
Table 87) refers to the number of additional bytes following Byte 1 and shall be set to zero. 


Note: Future revisions of CTA-861 may increase the length of the InfoFrame Descriptor 
payload by setting the Payload Length field to a non-zero value. Source devices shall use 
the Payload Length fields of both Short Vendor-Specific and Short InfoFrame Descriptors 
when locating the beginning of other structures following the Short InfoFrame 
Descriptors. 


Table 87 - Short InfoFrame Descriptor Header 


iS 
Da a a a | a ee | ee ee ee ee ee 


Payload Length (bytes) InfoFrame Type Code (any except codes 0x00 and 0x01) 


Table 88 - Short Vendor-Specific InfoFrame Descriptor Header 


a A a a a 


IEEE OUI third two hex digits 
IEEE OUI second two hex digits 
IEEE OUI first two hex digits 


Declared InfoFrame types shall be listed in order of priority; meaning that the first is the one 
that the display manufacturer has identified as most desirable. Sources may use this 
information as a basis for selecting which InfoFrames to send (e.g., in cases where the Source 
may not be capable of delivering all defined or supported InfoFrame types). 


7.5.10 YCpBCr 4:2:0 Video Data Block 


A YCgCr 4:2:0 Video Data Block (Y420VDB) lists Video Formats, supported by the Sink, that only 
allow YCgCr 4:2:0 sampling mode (i.e., do not support RGB, YCgCr 4:4:4, or YCgCr 4:2:2 sampling 
modes). Video formats represented as VICs that support RGB, YCpCe 4:4:4, or YCpCr 4:2:2 
sampling modes, in addition to YCgCr 4:2:0 sampling mode, shall be listed in a regular Video 
Data Block (see Section 7.5.1) and marked as supporting YCgCr 4:2:0 sampling mode using a 
YCgCr 4:2:0 Capability Map Data Block (see Section 7.5.11). 
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The structure of the Y420VDB is shown in Table 89. 


Table 89 - YCgCr 4:2:0 Video Data Block (Y420VDB) 


ee 2 ee 
CTA Tag Code (0x07) Length (L) = number of bytes following this byte 


CTA Extended Tag Code (Ox0E) 


ee YCpgCr 4:2:0-only SVDs (L-1 bytes) 
L+1 


Data bytes 3 through L+1 list SVDs in the same manner (including preference) as described in 
Section 7.5.1 for the regular Video Data Block. Sinks shall not use any reserved values for SVDs 
in the Y420VDB. 


SVDs from Y420VDBs may be included in the Video Format Preference Data Block (see Section 
7.5.12). 


7.5.11 YCpCr 4:2:0 Capability Map Data Block 


A YCgCe 4:2:0 Capability Map Data Block (Y420CMDB) indicates exactly which SVDs, listed in one 
or more regular Video Data Blocks (see Section 7.5.1), also support YCgCr 4:2:0 sampling mode 
— jin addition to other modes such as RGB, YCgCr 4:4:4, and/or YCgCr 4:2:2. The Y420CMDB 
does not indicate which RGB, YCsCr 4:4:4, and/or YCgCr 4:2:2 modes are supported. 


The structure of the Y420CMDB is shown in Table 90. 
Table 90 - YCgCr 4:2:0 Capability Map Data Block (Y420CMDB) 


a 
ot 


CTA Extended Tag Code (Ox0F) 


YCgCr 4:2:0 Capability Bit Map (L-1 bytes) 
L+1 


Data bytes 3 through L+1 contain a bit map indicating which Video Formats, relative to the set 
of SVDs listed in the regular Video Data Block(s) (see Section 7.5.1) of the EDID, support YCgCp 
4:2:0 capability. 


Bit O of data byte 3 is associated with the first sequential SVD listed in the regular Video Data 
Block(s) (see Section 7.5.1) of the EDID, bit 1 the second SVD, bit 2 the third, and so on. If any 
SVD beyond the first eight SVDs supports YCgCr 4:2:0 capability, then additional byte(s) shall be 
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provided, with bit ordering the same as byte 3 (e.g., with more than eight SVDs, bit 0 of byte 4 
would indicate the YCgCr capability associated with the ninth sequential SVD in the set of SVDs 
listed in the EDID). To save space, not all SVDs in the EDID need be marked relative to YCgCp 
4:2:0 capability (i.e., bytes that would be filled with all zero-bits and that are not followed by 
non-zero bytes do not need to be included). 


For SVDs that do not support YCgCr 4:2:0, the corresponding bit in the bit map of the 
Y420CMDB shall be set to O. For SVDs that do support YCgCe 4:2:0, the corresponding bit in the 
bit map of the Y420CMDB shall be set to ‘1’. 


When the Length field is set to L=1, the Y420CMDB does not include a YCgCr 4:2:0 Capability Bit 
Map and all the SVDs in the regular Video Data Block(s) (see Section 7.5.1) support YCgCr 4:2:0 
Sampling mode. 


7.5.12 Video Format Preference Data Block 


A Video Format Preference Data Block (VFPDB) indicates the order of preference for selected 
Video Formats listed as DTDs and/or SVDs throughout Block 0 and the CTA Extensions of the 
EDID. The VFPDB shall replace any other (legacy) preference assumptions. Almost all Video 
Formats indicated in the EDID may be used in the VFPDB. Exceptions are: 


e The Standard Timings in Block O 
e The Established Timings in Block O 
e Any DMT codes in T8VTDBs beyond the first code (see Section 7.5.17.2). 


In practical usage, Sources will only be concerned with the first 4-5 formats listed before their 
own preferences override the Sink’s indications. Only one VFPDB shall be listed in the EDID. 


The structure of the VFPDB is shown in Table 91. 
Table 91 - Video Format Preference Data Block (VFPDB) 
its 
pbyte# | 7 | 6 [ 5 | 4 [ 3 [2 fi 


CTA Tag Code (0x07) Length (L) = number of bytes following this byte 
CTA Extended Tag Code (0x0D) 


Short Video Reference 1 
Short Video Reference 2 
Short Video Reference 3 


L+1 Short Video Reference N 


Short Video Reference 1 refers to the most-preferred Video Format, while higher numbered 
SVRs (2, 3, through N) refer to Video Formats in order of decreasing preference. Short Video 
References (SVRs) refer to Video Formats via VICs and/or DTD indices. When indicated in the 
VFPDB, the 18-byte DTDs (contained within Block 0 or outside of the Data Block Collection Area 
of CTA Extensions) are enumerated in the order they appear and use contiguous SVRs starting 
with 129. The 20-byte DTDs and 6- or 7-byte CVT descriptors are enumerated in the order they 


132 


CTA-861-H 


appear (and may be interleaved with each other), and use contiguous SVRs starting with 145. In 
both cases, only the first 16 may be indicated. 


The Source shall interpret SVR codes according to the following pseudo code: 
If SVR == 0 then 
Reserved 
Elseif SVR >= 1 and SVR <= 127 then 
Interpret as a VIC 
Elseif SVR == 128 then 
Reserved 
Elseif SVR >= 129 and SVR <= 144 then 
Interpret as the K'" 18-byte DTD, where K = SVR - 128 (for K = 1 to 16) 
Elseif SVR >= 145 and SVR <= 160 then 
Interpret as the N‘" 20-byte DTD or 6- or 7-byte CVT-based descriptor, 
where N = SVR — 144 (for N = 1 to 16) 
Elseif SVR >= 161 and SVR <= 192 then 
Reserved 
Elseif SVR >= 193 and SVR <= 253 then 
Interpret as a VIC 
Elseif SVR == 254 then 
Interpret as the timing format indicated by the first code of the first T8VTDB 
Elseif SVR == 255 then 
Reserved 


End if 
7.5.13 HDR Static Metadata Data Block 


The HDR Static Metadata Data Block (HDR SMDB) indicates the HDR capabilities of the Sink and 
is defined below: 
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Table 92 - HDR Static Metadata Data Block (HDR SMDB) 


CTA Extended Tag Code (0x06) 


Desired Content Max Luminance data 


Desired Content Max Frame-average Luminance data 


Desired Content Min Luminance data 


Byte 1 indicates the length of the following data in the Data Block. CTA-861 defines a structure 
up to and including Byte 7. Future versions may have a different number of bytes in the Data 
Block: Source implementations shall parse this Data Block according to the length specified in 
Byte 1. 


Byte 3, bits 0 to 5, identify the Transfer Functions supported by the Sink: 
Table 93 - Supported Electro-Optical Transfer Function 


Supported EOTF 
Traditional gamma — SDR Luminance Range 
Traditional gamma — HDR Luminance Range 


Perceptual Quantization (PQ) based on SMPTE ST 2084 [41]*> 
Hybrid Log-Gamma (HLG) based on Rec. ITU-R BT.2100 [48] 
TF_4toTF_5 Reserved for future use (0) 


When TF_Ois set to ‘1’, the Sink indicates support for the Traditional Gamma — SDR Luminance 
Range as described in Section 6.9 Dynamic Range and Mastering InfoFrame. 


When TF_1 set to ‘1’, the Sink indicates support for the Traditional Gamma — HDR Luminance 
Range as described in Section 6.9 Dynamic Range and Mastering InfoFrame. This is intended to 
Support Sources without SMPTE ST 2084 [41] hardware capability. 


When TF_2 set to ‘1’, the Sink indicates support for the Perceptual Quantization (PQ) Transfer 
Function defined in SMPTE ST 2084 [41]. 


When TF_3 is set to ‘1’, the Sink indicates support for the Hybrid Log-Gamma (HLG) Transfer 
Function defined in Rec. ITU-R BT.2100 [48). 


24 These bits were referred to as ET_n in CTA-861-G and earlier. 


22 The Transfer Function TF_2 is equivalent to the Transfer Function in Rec. ITU-R BT.2100, where it is referred to as Perceptual 
Quantization (PQ). 
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TF_4to TF_5 shall be set to ‘0’. Future Specifications may define other Transfer Functions. 
Byte 4 indicates which Static Metadata Descriptors are supported. 


Table 94 - Supported Static Metadata Descriptor 


| SM in Supported Static Metadata Descriptor 
Static Metadata Type 1 


SM_1toSM_7 Reserved for future use (0) 


When SM_Ois set to ‘1’, the Sink indicates support for Static Metadata Type 1 (see Section 
6.9.1). 


The length of the data block, n, in Byte 1 indicates which of the Bytes 5 to 7 are present. Bytes 5 
to 7 are optional to declare. When n = 3, Bytes 5 to 7 are not present. When n = 4, Byte 5 is 
present; when n = 5, Bytes 5 and 6 are present; and when n = 6, Bytes 5 to 7 are present. When 
n> 3, each of Bytes 5 to 7 which are indicated to be present in the HDR Static Metadata Data 
Block may be set to zero. This value indicates that the data for the relevant Desired Max 
Content Luminance, Desired Content Max Frame-average Luminance or Desired Content Min 
Luminance is not indicated. 


Byte 5 indicates the Desired Content Max Luminance Data. This is the content’s absolute peak 
luminance (in cd/m?) (likely only in a small area of the screen) that the display prefers for 
optimal content rendering. Byte 5 contains an 8-bit value representing a perceptually coded 
value of the Desired Content Maximum Luminance. 


Byte 6 indicates the Desired Content Max Frame-average Luminance. This is the content’s max 
frame-average luminance (in cd/m?) that the display prefers for optimal content rendering. 
Byte 6 contains an 8-bit value representing a perceptually coded value of the Desired Content 
Max Frame-average Luminance. 


The luminance values represented by Bytes 5 and 6 are calculated from: 
Luminance value= 50 - 2'C¥/32) 
where CV (code value) is the decimal equivalent of the value of the byte. 


Byte 7 indicates the Desired Content Min Luminance. This is the minimum value of the content 
(in cd/m?) that the display prefers for optimal content rendering. Byte 7 contains an 8-bit value 
representing a perceptually coded value of the Desired Content Min Luminance and is 
calculated from: 


Desired Content Min Luminance = Desired Content Max Luminance - (CV/255)? / 100 


where CV (code value) is the decimal equivalent of the value of Byte 7. 


7.5.14 HDR Dynamic Metadata Data Block 


The HDR Dynamic Metadata Data Block (HDR DMDB) is shown in Table 95 below. 
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Table 95 - HDR Dynamic Metadata Data Block (HDR DMDB) 


ee es ea a ee ee ee 
CTA Tag Code (0x07) Length (L) of following data block (in bytes) 


CTA Extended Tag Code (0x07) 
Length of following data for supported HDR Dynamic Metadata Type n 
Supported HDR Dynamic Metadata Type n LSB 
Supported HDR Dynamic Metadata Type n MSB 
Support Flags for HDR Dynamic Metadata Type n 
Optional Fields for HDR Dynamic Metadata Type n 


Length of following data for supported HDR Dynamic Metadata Type m 
Supported HDR Dynamic Metadata Type m LSB 
Supported HDR Dynamic Metadata Type m MSB 
Support Flags for HDR Dynamic Metadata Type m 
Optional Fields for HDR Dynamic Metadata Type m 


The Supported HDR Dynamic Metadata Type indicates support for a specific type of HDR 
Dynamic Metadata, using the values of the Extended InfoFrame Type Codes as indicated in 
Table 53. Note that there is no requirement for the order of Supported HDR Dynamic Metadata 
Types in the Data Block, so Sources shall parse all bytes of the Data Block to establish a Sink’s 
support. 


When Supported HDR Dynamic Metadata Type has a value of 0x0001, Support Flags is as shown 
in Table 96: 


Table 96 - Support Flags for Supported HDR Dynamic Metadata Type 0x0001 


ee ee ee ee ee eee ee 


7 | 6 
F17=0 F16=0 F15=0 F14=0 type_1_hdr_metadata_ version 


In this case, a Sink supporting the HDR DMDB shall indicate which 
type_1 hdr_metadata_version it supports. 


When Supported HDR Dynamic Metadata Type has a value of 0x0002, Support Flags is as shown 
in Table 97: 


Table 97 - Support Flags for Supported HDR Dynamic Metadata Type 0x0002 


ee ee ee ee ee ee ee eee 


F17=0 s|_ hdr_mode_ support ts_ 103 433 spec_version 
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In this case, a Sink supporting the HDR DMDB shall indicate which ts_103 433 spec_version it 
supports and s|_hdr_mode_support shall indicate which processing mode(s) it supports, both as 
as specified in ETSI TS 103 433-1 [50]. Sinks shall not use a ts_103 433 spec_version value of 0. 


When Supported HDR Dynamic Metadata Type has a value of 0x0003, no Support Flags or 
Optional Fields are currently defined. In this case the HDR DMDB Byte 3, specifying the Length 
of following data for supported HDR Dynamic Metadata Type 3, shall be set to 0x02. 


When Supported HDR Dynamic Metadata Type has a value of 0x0004, Support Flags is as shown 
in Table 98: 


Table 98 - Support Flags for Supported HDR Dynamic Metadata Type 0x0004 


F17=0 F16=0 F15=0 F14=0 type_4 hdr_metadata_ version 


In this case, a Sink supporting the HDR DMDB shall indicate which 
type _4 hdr_metadata_version it supports. 


When Supported Extended InfoFrame Type has a value of 0x0100, Support Flags is as shown in 
Table 99: 


Table 99 - Support Flags for Graphics Overlay Flag Extended InfoFrame Type 0x0100 


F17=0 F16=0 F15=0 F14=0 graphics_overlay_flag_ version 


In this case, a Sink supporting the Extended InfoFrame Type 0x0100 shall indicate which 
graphics overlay_flag version it supports. 


Each Supported HDR Dynamic Metadata Extended InfoFrame Type may also indicate support 
for other optional fields relevant to that Type. No such Optional Fields are included in this 
specification. Therefore, the length of following data for each Supported HDR Dynamic 
Metadata Type is either 2 or 3, depending on the presence of Support Flags (indicating that no 
Optional Fields are present). 


The total amount of data required to indicate a Sink’s support may be larger than can be 
accommodated in a single HDR DMDB. In this case, multiple HDR DMDBs may be used to carry 
all such information and Sources shall parse all instances of these Data Blocks. Each HDR DMDB 
Shall contain all the data needed for any particular HDR Dynamic Metadata Type and shall not 
split that data over more than one HDR DMDBs. 
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7.5.15 Room Configuration Data Block 


The Room Configuration Data Block (RCDB) provides a more complete speaker layout and room 
description than is possible with the Speaker Allocation Data Block. There are three 
progressively increasing levels of speaker location detail using the RCDB: 


1) Using only the Speaker Presence Mask (SPM), allowing a selection of speakers and 
speaker pairs supported by the system. Using the SPM alone has no advantage over just 
using the Speaker Location Descriptor. 

2) Adding the Speaker Location Data Block (SLDB) with an associated Speaker Location 
Descriptor (SLD) for each speaker using named speaker locations. 

3) Adding spatial coordinates to one or more of the SLDs using the room coordinate 
system defined in Section 7.5.16.1, permitting a system to compensate for speakers that 
are either not ideally located or a location not defined by the named speaker locations. 


Additionally, the RCDB provides a means to describe the location of the display device using the 
room coordinate system. 


Note that the fully defined RCDB will set Length to 11 bytes. If spatial coordinates are not used 
(i.e. Display = 0 and/or COORD = 0 for all Speaker Location Descriptors) then the unused 
parameters should be truncated from the RCDB by reducing Length to 8 or even 5 bytes. 


Information in the RCDB can be in excess of, or in conflict with, the speaker definitions in the 
Speaker Allocation Data Block. If the source is capable of using the Room Configuration Data 
Block, then it shall ignore the Speaker Allocation Data Block (if present). 


138 


CTA-861-H 


The Room Configuration Data Block (RCDB) is shown in Table 100 below. 
Table 100 - Room Configuration Data Block (RCDB) 


a Ses ee ee ae 
CTA Tag Code (0x07) 


F67=0 F66=0 


If Display = 1, then the display values in bytes DISP1 through DISP3 shall contain valid data. 


If Soeaker = 1 then Speaker Count shall be valid. If Soeaker = 0, then Speaker Count shall not be 
used to determine the number of PCM audio channels. 


If SLD = 1, then Speaker Location Descriptors shall be present for every speaker defined by the 
system and Speaker shall be set to 1. If SLD = 0, then Speaker Location Descriptors are not 
available and only the SPM fields shall be read to describe the speaker layout. 


If Soeaker = 1, the 5 bit unsigned integer value Speaker Count shall be equal to the total 
number of L-PCM channels - 1. If Soeaker = 0, Soeaker Count shall be set to 0. A valid Speaker 
Count is optional for configurations described only with an SPM flag, and mandatory for 
configurations described using at least one Speaker Location Descriptor (see Section 7.5.16). 


The channel-name mnemonics used in the Speaker Presence Mask (SPM1 - SPM3) are found in 
Section 7.5.3 and the SPM1-SPM3 fields are otherwise identical to the Speaker Allocation Mask 
defined in Section 7.5.3. The flags in these 3 bytes indicate the presence of speakers by name. 
Speakers present shall be indicated by setting the respective flag to 1 and the remaining flags 
Shall be set to O. 


For L/R paired positions, the corresponding flag in the SPM shall be set to 1 only if both 
speakers exist. Soeakers that are a part of an incomplete pairing can only be represented using 
the Speaker Location Descriptor. 


28 Use of F46 for RLC/RRC has been deprecated. RLC/RRC are considered to be logically the same speaker positions as BL/BC. 
Legacy Sinks might use RLC/RRC instead of BL/BR; Sources shall route audio intended for RLC/RRC to BL/BR. See Table 35 and 
Table 41. Future use of F46 for other speaker positions is reserved. 


27 Use of F63 for TpLS/TpRS has been deprecated. Future use of F63 for other speaker positions is reserved. 
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The SPM shall be configured even when the SLDB is used. At a minimum it should advertise the 
channels indicated by the Speaker Allocation Data Block. 


Note that a discrepancy between SPM1 — SPM3 and Speaker Count is possible for systems using 
Speaker Location Descriptors. 


Xmax is an unsigned 8-bit integer equal to the absolute value of the maximum distance along 
the X axis from the Primary Listening Position (PLP) to the furthest speaker in decimeters. Xmax 
Shall be valid if Display = 1 or if COORD is set for any SLD. If Xmax is not present in the RCDB, 
then it shall have a default value of 0x10, which represents 32 dm (3.2 meters). 


Ymax is an unsigned 8-bit integer equal to the absolute value of the maximum distance along 
the Y axis from the PLP to the furthest speaker in decimeters. Ymax shall be valid if Display = 1 
or if COORD is set for any SLD. If Ymax is not present in the RCDB, then it shall have a default 
value of 0x10, which represents 32dm (3.2m). 


Zmax is an unsigned 8-bit integer equal to the absolute value of the maximum distance along 
the Z axis from the PLP to the furthest speaker in decimeters. Zmax shall be valid if Display = 1 
or if COORD is set for any SLD. If Zmax is not present in the RCDB, then it shall have a default 
value of 0x08, which represents 16 dm (1.6m). 


DisplayX is a Coordinate Value normalized to Xmax equal to the distance between the PLP and 
the center of the display along the x-axis. Table 103 in Section 7.5.16.1 describes the 
Coordinate Value format. If DisplayX is not present in the RCDB, then it shall have a default 
value of 0x00 (0.0*Xmax centered on the PLP). 


DisplayY is a Coordinate Value normalized to Ymax equal to the distance between the PLP and 
the center of the display along the y-axis. Table 103 in Section 7.5.16.1 describes the 
Coordinate Value format. If DisplayY is not present in the RCDB, then it shall have a default 
value of 0x40 (1.0*Ymax in front of the PLP). 


DisplayZ is a Coordinate Value normalized to Zmax equal to the distance between the PLP and 
the center of the display along the z-axis. Table 103 in Section 7.5.16.1 describes the Coordinate 
Value format. If DisplayZ is not present in the RCDB, then it shall have a default value of 0x00 
(0.0*Zmax, aligned in the vertical plane of the PLP). 


Note: Only the location of the display is expressed here. The display’s width and height 
are available from the 'Max Horizontal Image Size’ and ‘Max Vertical Image Size’ fields 
that are assigned on address 0x15 and 0x16 in the VESA E-EDID specification. HDMI 
provides additional means to define the value range of the VESA Image Size parameter, 
and that feature should be set accordingly. 


7.5.16 Speaker Location Data Block 


The Speaker Location Data Block (SLDB) is described in Table 101. Multiple SLDBs may be 
required to contain all of the Speaker Location Descriptors need to describe a system. 
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Table 101 - Speaker Location Data Block (SLDB) 


Byte# oP 7 tt 
CTA Tag Code (0x07) Length of following block payload (bytes) 


ae ee CTA Extended Tag Code (0x14) 


3 through . | 
Length +1 Speaker Location Descriptors 


The Speaker Location Descriptor, shown in Table 102, is a data structure for providing 
additional information about a particular channel. The Speaker Location Descriptor shall only be 
used when the corresponding parameters SLD and Speaker Count have been set in the RCDB 
(see Section 7.5.15). It describes one PCM channel with a Channel Index, a Speaker ID, and 
optionally, soeaker coordinates. It occupies 2 or 5 bytes, depending on the flags in the first 
byte. 


Table 102 - Speaker Location Descriptor 


Pp Byes Po7 | 6} os | et 
F17=0 COORD Channel Index (0 to 31) 


| IDs sF27=0 F26=0 F35=0 Speaker ID (0 to 31) (from Table 40) 


COORD3 


Channel Index is the index of the audio channel where the audio for the described speaker is to 
be transmitted. See also Section 6.6.4. 


A source shall order the channels following these implementation guidelines: 


1) The channel indices (from 0 to 31) will indicate the ordering of the L-PCM feeds being 
delivered. 

2) Pairs should be kept together, with the “R” on the second channel of a channel pair. 

3) Duplicate speaker IDs are in consecutive channel indices. 


If Active = 1, then the channel shall be rendered on a speaker by the Sink. If Active = 0, the 
respective channel is unused. The total number of Active flags set to 1 shall match the Speaker 
Count in the Room Configuration Data Block. At most one SLD carrying a given Channel Index 
Shall have the Active flag set to 1, any others shall set Active to 0. 


If COORD = 1, then the three bytes COORD1, COORD2 and COORDS shall be present and the X, 
Y and Z fields shall contain valid data. If COORD = 0, the COORD1, COORD2, and COORD3 bytes 
shall not be present in the Speaker Location Descriptor. 


If COORD = O, Speaker ID shall identify the corresponding named location of the speaker being 
defined (see Table 40). In this case, Soeaker ID shall be unique. 
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If COORD = 1, Speaker ID should indicate the named location of the speaker most closely 
representing the position indicated by the coordinates, otherwise it shall be set to 31. Note that 
Speaker ID may not be unique. 


X is a Coordinate Value normalized to Xmax equal to the distance between the PLP and the 
position of this soeaker along the x-axis. Table 103 in Section 7.5.16.1 describes the Coordinate 
Value format. 


Y is a Coordinate Value normalized to Ymax equal to the distance between the PLP and the 
position of this soeaker along the y-axis. Table 103 in Section 7.5.16.1 describes the Coordinate 
Value format. 


Z is a Coordinate Value normalized to Zmax equal to the distance between the PLP and the 
position of this soeaker along the z-axis. Table 103 in Section 7.5.16.1 describes the Coordinate 
Value format. 


7.5.16.1 Room Coordinate System 


The CTA Room Coordinate System describes the spatial location of components in a viewing 
and/or listening environment, such as the speakers and the display. These coordinates can then 
be translated to suit the needs of the various OBA rendering algorithms used to create a 
customized listening experience. 


The origin of the Room Coordinate System is defined to be the most optimal seated listening 
position in the room. This is denoted as the Primary Listening Position (PLP). 


The Room Coordinate System shall be based on a rectangular box that contains all of the 
components of interest centered on the PLP. 


Xmax, Ymax and Zmax shall define the extremities of this box expressed as unsigned integer 
values in decimeters (dm)2°. Note that this will describe rooms as large as 51 meters on each 
axis. 


The X-axis is positive to the right of the PLP, from the perspective of the listener. 
The Y-axis is positive from the PLP going forward toward the Display. 
The Z-axis is positive from the PLP going Up. 


The coordinate values along each axis shall be normalized by the maximum absolute excursion 
on that axis. 


The procedure for characterizing a room shall be as follows: 


The point of measurement for the display position shall be the center of the viewing area on 
the display surface. 


281 dm = 10cm = 100 mm = approximately 4 inches 
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The point of measurement for each speaker is at the acoustic center on the inward facing 
surface for direct speakers, and the acoustic center of the reflected or virtual sound field for 


reflected and virtualized speakers. 


Normalized parameters are represented in 1.6 signed two’s complement format, as in Table 
103 below: 


Table 103 - Coordinate Value Format 


ree | eee 
Ese eae ERED 


sl Slee Me I a Ae 


S = sign bit (MSB). If the sign bit (S) equals zero, then the Coordinate Value is positive. If the 
sign bit (S) equals one, then the Coordinate Value is negative. 


| = integer portion. 


F = fractional portion. Since there are 6 fractional bits, the scaling factor is 1/2° = 1/64. For 
example, a value of 11111111b = -1/64. 


The Coordinate Value Format represents values from -2 to +1.984375 in steps of .015625 or 
(1/64). 


For example, if Xmax = 30 dm, (3 m), then the unit resolution of the axis is about 5 cm. 
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7.5.17 DisplayID Video Timing Data Blocks 


Three VESA DisplayID [57] data structures are available for use as advanced video timing 
descriptors, contained within separate Data Block types. The data structures are the VESA 
Type VII 20-byte Detailed Timing Descriptor (DTD) Data Block, the VESA Type VIII Detailed 
Monitor Timing (DMT) Data Block, and the VESA Type X Coordinated Video Timing (CVT) Data 
Block. 


The usage of these DisplayID data structures within CTA-861 Data Blocks require the use of an 
additional wrapper in the form of the standard Tag+Length byte. The balance of the data 
structures are taken directly from DisplayID, starting with the first two bytes of the DisplayID 
Data Block header, consisting of the Data Block Identification, and the Block Revision and Other 
Data fields. (The redundant Number of Payload Bytes field is not used.) The Data Block 
Identification tag is used as the CTA Data Block Extended Tag. 


Multiple instances of these Data Blocks may exist in the EDID as each is subject to the 32-byte 
Data Block limit. It may be desirable to use two different Data Blocks for Type VIII timings, one 
with the Y420 bit set (indicating that the timings within all support YCgCe 4:2:0) and one with 
the Y420 bit cleared (indicating none of the timings within support YCgCr 4:2:0). 


If the preferred video timing in a VTDB is also the native resolution of the display, the Sink shall 
not set any Native bits in the VDB’s SVDs and CTAX_NATIVE_DTDS shall be set to 0. None of the 
VTDBs contain information that they represent the Native Video Resolution. (See Section 
7.5.12.) 


7.5.17.1 DisplayID Type VII Video Timing Data Block 


The Type VII Video Timing Data Block (T7VTDB) is an expansion of the legacy 18-byte Detailed 
Timing Descriptor from the E-EDID v1.3 standard [9]. Whereas 18-byte DTDs are limited to 4095 
pixels, 4095 lines, and a 655.36 MHz pixel clock, the 20-byte DTD supports up to 64k pixels and 
lines, and pixel rates up to 16 GHz. 


Table 104 shows the structure of the T7VTDB within a CTA Extended Data Block using the 
Extended Tag Code of 34 (0x22). The payload for this Data Block is a single 20-byte DTD as two 
of these DTDs would exceed the CTA Data Block limit of 32 bytes. 


144 


CTA-861-H 


Table 104 - DisplayID Type VII Video Timing Data Block (T7VTDB) 


Byte# | 7 | 6 | 5 | 4 | 3 | 2 | 1 
1 Tag Code (0x07) Length (L) = number of bytes following this byte 
Extended Tag Code = 34 (0x22) 
Block Revision = 010b 
Pixel Clock (in kHz) Low Bits 7:0 
Pixel Clock (in kHz) Middle Bits 15:8 
Pixel Clock (in kHz) High Bits 23:16 
T7_Aspect_Ratio 
Horizontal Active Image Pixels Low Bits 7:0 
Horizontal Active Image Pixels High Bits 15:8 
Horizontal Blank Pixels Low Bits 7:0 
Horizontal Blank Pixels High Bits 15:8 
Horizontal Offset (Front Porch) Low Bits 7:0 
Horizontal Offset (Front Porch) High Bits 14:8 
Horizontal Sync Width Low Bits 7:0 
Horizontal Sync Width High Bits 15:8 
Vertical Active Image Lines Low Bits 7:0 
Vertical Active Image Lines High Bits 15:8 
Vertical Blank Lines Low Bits 7:0 
Vertical Blank Lines High Bits 15:8 
Vertical Offset (Front Porch) Low Bits 7:0 
Vertical Offset (Front Porch) High Bits 14:8 
Vertical Sync Width Low Bits 7:0 
Vertical Sync Width High Bits 15:8 


- — 
NJ © 


PlP/P |e 
o | U1 | & |W 


|e 
WwW | 00 


= 
~“ 


NI 


= ee 
ae 
2 ay 
| 4 
| 5 
| 6 
| 8 
=a 
| 10 | 
| 42 
| 13 | 
| 14 
| 15 | 
| 16 | 
| a7 
| 18 
| 19 
| 20 | 
| 21 
| 22 | 
23 


Byte 3 contains the revision of the data structure and the variable-length indication of the 
descriptor. The revision supported by CTA-861 is 010b; future versions of DisplayID may 
support additional revisions. The DSC_PT field has reserved usage for VESA DisplayID; for use 
with CTA-861, it shall be cleared (=0). The T7_M field identifies the length of the descriptor 
beyond the original 20-byte length: the descriptor length = 20 + T7_M. The T7_M shall be O00Ob; 
all other values are reserved. 


The T7Y420 field indicates support for YCgCr 4:2:0 sampling mode. When T7Y420=1, the timing 
format shall support both RGB and YCgCr 4:2:0 sampling mode. When set to zero, the timing 
format does not support YCgCe 4:2:0. (See Section 7.5.17.4.) 


The T7HSP field indicates the horizontal sync polarity, positive when set to one, and negative 
when set to zero. The T7VSP fields indicates the vertical sync polarity, positive when set to one, 
and negative when set to zero. DisplayID uses T7IL to indicate if the timing is interlaced or 
progressive; however, CTA-861 only supports progressive timings for 20-byte DTDs, so this bit 
shall always be set to zero. 
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Table 105 describes the aspect ratio encodings and Table 106 the 3D_Support encodings. As 
with 18-byte DTDs, the refresh rate is calculated by dividing the Pixel Clock by the product of 
the horizontal and vertical totals: Refresh_rate = PCLK / [(Horizontal_ active + Horizontal_ blank) 
x (Vertical_ active + Vertical_blank)]. 


Table 105 - Type VII Aspect Ratio 


T7_Aspect_Ratio Aspect ratio 


[| 256:135 
Calculated by Horizontal Active Image Pixels and 
Vertical Active Image Lines 


All others 


Table 106 - 3D Stereo Support 


3D _Support 
fF  00b ss Shall always be displayed in mono 
Shall always be displayed in stereo 


10b Shall be displayed in mono or stereo, depending on a 
user action 


Any 20-byte DTDs described in T7VTDBs may also be used in the Video Format Preference Data 
Block. The T7VTDB shall not be used with a video timing that can be expressed in an 18-byte 
DTD. The T7VTDB shall not be used with any video timing that can be expressed using a 
T1OVTDB. 


7.5.17.2 DisplayID Type VIII Video Timing Data Block 


The Type VIII Video Timing Data Block (T8VTDB) is similar to the Video Data Block (VDB) in that 
it can contain a list of single-byte codes that represent timing formats from a given standard. 
The T8VTDB may also be used with two-byte codes. In DisplayID, the codes are sourced from 
the VESA DMT standard, CTA-861, and HDMI 1.4b. The T8VTDB shall not be used with CTA-861 
or HDMI 1.4b single-byte VICs as those codes have more-efficient locations in the EDID (the 
VDB and the HDMI VSDB, respectively). In the future, CTA-861 may expand its VIC usage to two 
bytes for which the T8VTDB may be used. 


Currently, the T8VTDB may be used with either single-byte DMT ID Codes or Standard two-byte 
Codes from the VESA DMT specification [124]. Each Data Block shall contain only one-byte 
codes, or only two-byte codes, as indicated in Byte 3 bit 3. Multiple T8VTDBs may exist in an 
EDID. The T8VTDB shall not be used to advertise a timing format that may be expressed by an 
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Established Timings field. The T8VTDB shall not be used to advertise a timing format that may 
be expressed using a Standard Timing ID two-byte field unless all 8 IDs have been used, nor 
Shall it be used with one-byte codes when a two-byte version can be stored as a Standard 
Timing ID. The T8VTDB shall not be used to advertise a CTA-861 timing listed in the DMT (such 
as the one-byte 0x52 or the two-byte [0xD1, OxCO] codes for 1080p60). 


Only the First Timing Code in the EDID’s first T8VTDB may be used as a preferred Video Format 
in the VFPDB (Section 7.5.12). 


Table 107 shows the structure of the T8VTDB within a CTA Extended Data Block using the 
Extended Tag Code of 35 (0x23). The payload for this Data Block is at minimum one code, and 
at maximum 28 one-byte codes or 14 two-byte codes. 


Table 107 - DisplayID Type VIII Video Timing Data Block (T8VTDB) 


Byte 3 contains revision and YCgCr 4:2:0 support identical to that of the T7VTDB. The revision 
supported by CTA-861 is 001b; future versions of DisplayID may support additional revisions. 
When T8Y420=1, all timing formats in this T8VTDB shall support both RGB and YCgCr 4:2:0 
sampling mode. When set to zero, the timing formats do not support YCgCr 4:2:0. (See Section 
7.5.17.4.) 


The Timing Code Size (TCS) bit indicates two-byte codes (N=2) when set to one, and one-byte 
codes (N=1) when set to zero. The value N is used to calculate the Byte # in Table 107. Two- 
byte codes are stored with the LSB in the lower Byte #. 


Table 108 shows the encodings for Code_Type. Only DMT codes shall be used. 
Table 108 - Code Type Indication 


Code_Type Index Standard 
DMT Timing Code (1-byte or 2-byte) 
All others 


7.5.17.3 DisplayID Type X Video Timing Data Block 
The Type X Video Timing Data Block (TLOVTDB) is used to advertise IT timing formats in a more 


efficient manner than a DTD, as each entry requires six or seven bytes. The timing formats 
listed in the T1OVTDB must conform to the VESA Coordinated Video Timing (CVT) formula, and 


147 


CTA-861-H 


may use standard- or reduced-blanking. Since CE timing formats in CTA-861 do not conform to 
the CVT standard, VIC timing formats cannot be advertised in the TIOVTDB. Multiple TIOVTDBs 
may exist in an EDID. The T1OVTDB shall not be used to advertise a timing format that may be 
expressed by an Established Timings field. The T1OVTDB shall not be used to advertise a timing 
format that may be expressed using a Standard Timing ID two-byte field unless all 8 |IDs have 
been used. 


Table 109 shows the structure of the TLOVTDB using 6-byte descriptors and Table 110 shows 
the structure of the TLOVTDB using 7-byte descriptors, contained within CTA Extended Data 
Blocks using the Extended Tag Code of 42 (0x2A). The payload for this Data Block is at minimum 
one descriptor, and at maximum, four descriptors. The descriptors in TLOVTDBs may be used in 
the VFPDB (Section 7.5.12). 


Table 109 - DisplayID Type X Video Timing Data Block (T10VTDB), T10_M=0 


a a eee 
7 | 6 | 5s | a 8 
Tag Code (0x07) Length (L) = number of bytes following this byte 
Block Revision = 000b 
Timing_Formula 


Tag Code (0x07) 
Block Revision = 000b 
First Descriptor 
Horizontal Active Image Pixels Low Bits 7:0 
Horizontal Active Image Pixels High Bits 15:8 
Vertical Active Image Lines Low Bits 7:0 
Vertical Active Image Lines High Bits 15:8 
Refresh Rate Low Bits 7:0 
Refresh Rate 
High Bits 9:8 
Second Descriptor (if present) 
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Byte 3 contains the revision of the data structure and the variable-length indication of the 
descriptor. The revision supported by CTA-861 is OOOb; future versions of DisplayID may 
support additional revisions. The T10_M field identifies the length of the descriptor beyond the 
original 6-byte length: the descriptor length = 6+ T10_ M. The T10_M shall be OOOb or 0015; all 
other values are reserved. All descriptors in a T1OVTDB are of the same length as indicated by 
T10_M. 


The VR_HB bit defines either the Video Refresh Rate Option or the Horizontal Blank Option, 
depending on the Timing Formula. Table 111 shows the available settings. When the Timing 
Formula indicates an algorithm other than RB2 or RB3, VR_HB shall be cleared (=0). 


Table 111 - Definition of VR_HB 


Timing _Formula VR_HB CVT Algorithm 
sionaen Lo | Refresh Rate x 1000/1001 is not supported 
Refresh Rate x 1000/1001 is supported, in addition to 1:1 


011b (RB3) | Horizontal Blank is 80 pixels 
Horizontal Blank is 160 pixels 
Rsvd (0) 


The T10Y420 field indicates support for YCgCr 4:2:0 sampling mode. When T10Y420=1, the 
timing format of this descriptor shall support both RGB and YCgCr 4:2:0 sampling mode. When 
set to zero, the timing format does not support YCgCr 4:2:0. (See Section 7.5.17.4.) 


The CVT formula takes in five parameters: the active horizontal pixel count; the active vertical 
line count; the refresh rate in Hz; a timing formula enumeration for the algorithm; and a 
Boolean (indicated by VR_HB) for either the refresh rate ratio or horizontal blank. The 
3D_Support field is encoded as per Table 106. The Timing Formula field is encoded as per Table 
112. Sources supporting T1IOVTDBs shall support all defined algorithms listed. Note that future 
versions of the algorithm may be defined; Sinks shall ignore algorithm versions they do not 
understand and shall not be adversely affected by them. 


Table 112 - CVT Timing Formula 


Timing Formula CVT Algorithm 
000b v1.2 standard timing 
001b v1.1 reduced-blanking (RB1) 


010b v1.2 reduced-blanking (RB2) 
011b v1.3 reduced-blanking (RB3) 


7.5.17.4 DisplayID Video Timings Data Blocks and Pixel Encodings 


The following Pixel Encodings shall be supported by the formats in the VTDBs: 
¢ RGB is always supported. 
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© YCpCe 4:4:4 and 4:2:2, are supported if indicated in byte 3 bits 5..4 of the CTA Extension; 
otherwise, not supported. 


¢ YCpCr 4:2:0 is supported when the respective bit is set to one in the VTDB header. 


Support for these encodings may be constrained by the interface’s clock limits. Additionally, 
YCgCr 4:2:0 support may be limited by the IDO (e.g., HDMI does not support YCgCr 4:2:0 pixel 
encoding when the base Pixel Clock is below 590MHz). 
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7.6 Multiple Instances of Data Blocks 


As noted in Section 7.4, EDIDs may contain more than one instance of a specific type of data 
block in its 


CTA Extension(s). This may be desirable for many reasons: the need to stretch the information 
across 


Extension boundaries; the desire to place “advanced” features in a second Extension that 
legacy devices 


will not be exposed to; or to make adding and subtracting Short Audio descriptors easier in 
firmware. Table 113 lists the rules for allowing multiple instances of all Data Blocks and how 
multiple instances are handled. 


Table 113 - Rule List for Data Blocks 


Tags Concatenation 
2 
Vendor-Defined 
4,5 Not Applicable 
0, 2, 5, 6 Not Applicable 
Vendor-Defined 

Not Applicable 

Not Applicable 

Not Applicable 

Not Applicable 
Vendor-Defined 

Not Applicable 

Not Applicable 

Not Applicable 

Not Applicable 

Not Applicable 


3 


|Tags 
pea! 
a 


>| =) =) 
<|< < < 


1. For definition, see HDMI Forum’s latest HDMI Specification 


Where the rules are “Allowed, Any”, the Sink may have multiple instances but the Source is not 
required to maintain descriptor order as the payloads do not contain an intrinsic order (e.g., 
SADs in ADBs may appear in any order). 


Where the rules are “Allowed, Vendor-Defined”, Sinks are allowed to have multiple instances of 
the data block type, but each instance of the same type has a second layer of identification that 
limits duplication. In other words, Sinks shall not have multiple instances of these data blocks 
where the combination of Tag(s) and secondary identification are the same. All of the Vendor 
Specific data blocks fall into this category and include OUls as part of the secondary 
identification. Vendor Specific data blocks may include additional vendor-defined secondary 
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identification information in the payload to be used in conjunction with the OUI, such asa 
header that indicates the type and version of the data block. Thus, Sources shall parse the OUIs 
and any vendor-defined secondary identification information to determine how multiple 
instances of Vendor Specific data blocks are to be interpreted. 


Where the rule is “Not allowed”, Sinks shall not contain more than one instance of any one type 
of data block. For example, an EDID shall not contain two Speaker Allocation Data Blocks 
(SADBs) as the information in each has the potential to be conflicting. Sources shall ignore 
additional instances of these data blocks where the Tag(s) are identical, parsing only the first 
one. 


Where the rule is “Reserved”, either the Tag is currently reserved in this specification, or where 
assigned to an IDO, is undefined by that organization. Sinks shall not include any of these data 
blocks and Sources shall ignore them. 


Additional rules between data block instances — such as the SADB being ignored if the Source 
parses the RCDB — are covered in Section 7.5 and are not changed by these rules. 
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ANNEX A BASELINE EXAMPLE EDID AND DETAILED TIMING DESCRIPTORS 
(INFORMATIVE) 


This Annex provides a baseline example EDID for features and functions contained in CTA-861. 
The example EDID presented here is not meant to illustrate all conceivable combinations for 
data block types or lengths. For example, Annex D provides another example EDID for use with 
the HDMI implementation of CTA-861. 


Annex A addresses issues related to the VESA Extended Display Identification Data (EDID) tables 
utilized within CTA-861. 


Annex A provides examples and guidance to manufacturers that utilize CTA-861; however 
included in this Annex are several normative requirements identified by the "shall" verb. 
Specifically, this guidance is for the implementation of EDID tables. Primarily, the motivation is 
to help insure interoperability between various Sources and Sinks. Annex A should in no way 
prohibit consumer device manufacturers from including additional features, and Annex A 
should not be interpreted as stipulating any form of upper limit to EDID features. 


A.1 Background 


CTA-861 follows requirements in the VESA Enhanced Extended Display Identification Data 
Standard (E-EDID). EDID tables exist within the Sink and are used to declare its capabilities to 
Sources. The Source uses these declared capabilities to determine the appropriate signal 
parameters to send across the interface for consumption by the Sink. 


Possibly, there are varied and inconsistent ways to create EDID tables and therefore, a common 
methodology is desirable to help insure interoperability between various Sink and Sources. The 
purpose of Annex A is to provide a consistent and understandable guideline for creating EDID 
tables that reside within consumer electronics products. Consequently, Annex A does not 
address implementations that utilize repeaters. 


A.2 EDID Tables 


CTA-861 requires use of the VESA EDID version 1, revision 3 data structure. Previous versions of 
EDID are not supported and such use is deprecated. EDID Version 1, Revision 3 requires use of 
certain features for Computer Displays. Despite these requirements, some features are not 
applicable to certain display technologies and applications. For example, the Monitor Range 
Limits descriptor and support of the Generalized Timing Formula apply to CRT based multi-scan 
systems and not flat panel or most consumer electronics equipment. For consumer electronics 
devices (CE devices) the application is limited to a simple declaration of the Sink’s capabilities 
and attributes. This section provides an outline describing the various blocks that reside with 
the EDID structure. 
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A.2.1 EDID Table Construction 


The table construction is divided into blocks dedicated to specifying various attributes. Each 
block is 128 bytes in length. Block 0 is mandatory and the following blocks are called 
“extensions”. The extensions are limited to 254 blocks. 


It is possible to use the first extension as a data block or as an index (EDID Block Map Extension) 
that lists more than one extension. When only one extension is required, it is called Block 1 and 
is used for data. In cases where more than one extension is required, the first extension or 
Block 1 is used as an index map that lists extension locations. Additional extensions are referred 
to as Blocks, such as Block 2, Block 3, and so on. 


Each extension contains a Block Tag that declares the contents of each extension. Sources 
should read Block O (at address 0x7E), check for multiple extensions, identify each block or 
extension, and be able to appropriately interpret the data contained therein. Users should be 
knowledgeable of defined Tags contained within Section 2.2.1.4 of the VESA E-EDID standard. 


Sources should read all extensions and Block Tags. CTA Extension Version 1 or Version 3 
specifies additional Video Formats as necessary. There are three possible versions of the CTA 
Extension and Sources should read the contents of the extension even if they cannot recognize 
the version number. This is to ensure that the Detailed Timing Descriptors are read. 


For CE devices, the number of extensions or blocks is dependent upon the amount of supported 
Video Formats and features. Annex A shows one extension containing four Detailed Timing 
Descriptors (see Section A.2.20). 


A.2.2 Detailed Explanation of EDID Block Zero 


For this discussion, block zero and subsequent extension blocks are divided into smaller 
sections, each receiving an explanation of terminology and use. The contents in each section 
are a possible example of a typical CE device application. 


A data format protocol is required to properly utilize the various blocks. Data within the various 
blocks is placed in fields with varying bit lengths. These lengths range from one bit to two bytes. 
The data length convention is defined and shown in Table 114 . 


Table 114 - Standard Data Lengths 


16 bits (two bytes) Binary, LSB first 


Greater than two bytes: ASCII code, consecutive string order, ex: HDTV = 0x48, 0x44, 0x54, 0x56 
(Character string) 
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A.2.3 Block Zero Header Section 


The header is comprised of eight addresses, Ox00 through 0x07, containing a simple binary data 
pattern that is used to identify the EDID table. There is one byte per address for a total of eight 
bytes. Address locations 0x00 and Ox07 contain data values 0x00 and locations 0x01 through 
Ox06 contain OxFF as data values. CTA-861 requires this data. This header is used to determine 
the beginning of an EDID structure in a Sink. See Table 115. 


Table 115 - Block Zero Header 


Address Hex | Example Data 
Hex Dec 


/oxoo. =——s«f x00} OCSY Binary These fixed values are 
REQUIRED to properly identify 
start of EDID table data 


Loxo7 | x00 TO 


Although future versions of EDID may not contain an 8-byte header at the beginning of Block O, 
compliant devices are expected to use this header. However, presence of the header is not an 
indication that the following EDID data is valid. A checksum byte is provided for the purpose of 
verifying that a device’s EDID structure has been correctly read. See Section A.2.11 for more 
detail. 


A.2.4 VENDOR / PRODUCT IDENTIFICATION 


This section’s example starts and ends with address locations 0x08 and 0x11. Byte allocation for 
each location is as follows: 


Ox08 ~ Ox09 are a two byte PNP ID for Manufacturer Name and should contain a valid 
identification number. Data for these bytes is based upon compressed ASCII, for example: 
“CTA” is created by using five-bit codes, where “C” = 00011. “E” = 00101, and “A” = 00001. 
Table 116 illustrates the address location and sample data for Manufacturer's Name, which is 
“CTA”. For information on how to obtain a PNP ID, see Unified Extensible Firmware Interface 
Forum — PNP ID AND ACPI ID REGISTRY [127]. 


OxOA ~ OxOB are two bytes available for Product code; the manufacturer determines this code. 


OxOC ~ OxOF are four bytes to be used for product Serial Number, which is defined as a 32-bit 
serial number. There is no specific requirement defined for the data or format of the serial 
number. This field should be zero if the serial number is contained in an ASCII serial number 
descriptor (see Section A.2.17). CTA-861 implementations should use 0x00 as padding for the 
Block O serial number if no serial number is provided in Block O. 


155 


CTA-861-H 


For the Source, if an ASCII Serial Number Descriptor is included in the Sink, then the Source 
should ignore the Serial Number field in Block 0. If no ASCII Serial Number Descriptor is present, 
then the field may have meaning. Ignore this block if all bytes are Ox00. 


0x10 is one byte for Week of Manufacture. The designated values for this field range from 1 to 
53. Values greater than 53 are not recognized. Zero may be used when no week is designated. 
The manufacturer determines the week numbering system. Manufacturers should use a system 
in which the week number's integer value increases as the year progresses. If a manufacturer 
chooses to declare only the Model Year (in the field "Year of Manufacture"), then OxFF shall be 
placed in Address 10 (Week of Manufacture). 


Ox11 is one byte representing Year of Manufacture. This value is determined by the actual year 
of production minus 1990. For example: 2002 - 1990 = 12 or OxOC. See Table 116. 


Table 116 - Vendor / Product Identification; Showing Manufacturer Week and year 


Address Example Data Description 
toe [ieee fe 
Example = CTA 


Product Code Used to differentiate 
OxOB 0x34 52 between different models 
from the same manufacturer. 
In this example Product 
Code=0x3412 


|oxoc | x56 | 86 Serial Number Optional. 
The serial number can also be 
stored in a separate 


OxOF OxBC 188 descriptor block (see Section 
A.2.17). In this example, the 
Serial Number=0xBC9A7856. 


0x10 0x10 16 Week of Manufacture If this field is unused, the 
value should be set to O. If 
the next field is used for 
Model Year, then OxFF should 
be set. In this example 
Manufacture Week=16 


Ox11 Ox0C 12 Year of Example = Manufactured 
Manufacture/Model Year Year=2002 


A.2.5 EDID Version 


The version of EDID is declared in addresses 0x12 and 0x13. Each address contains one byte of 
data. The first address contains the version number and the second, the revision number. In the 
case of EDID version 1, revision 3, the value one (0x01) is placed in the first location (i.e., 0x12) 
and three (0x03) placed in the second area (0x13). No other numbers are allowed for this space. 
If other numbers are placed in this area, the Source may disregard the whole EDID table. See 
Table 117. 
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Table 117 - Vendor / Product Identification 


— | —— 


pOx12 x0. pt | Binary Version # # 


Spor 


A.2.6 Basic Display Parameters and Features 


Basic Display Parameters and Features are defined as Video Input Definition, Maximum 
Horizontal Image Size, Maximum Vertical Image Size, Display Transfer Characteristic (Gamma), 
and Feature Support. In the following example, each item is allocated one byte and the address 
range is from 0x14 to 0x18. 


0x14: Video Input Definition is located at 0x14 and used to identify the output configuration 
required by the Sink. For digital displays, including CE devices, the recommended setting is 
Ox80. This value is used to declare that the device supports a digital interface. 


0x15 ~ 0x16: The Maximum Horizontal Image Size and Vertical Image Size fields (bytes 0x15, 
0x16) are used to indicate the Sink’s screen size and aspect ratio. When known, the maximum 
physical dimensions of the effective display area should be provided (in these fields, in cm). An 
important use of these fields is to indicate the aspect ratio of the actual screen. If the aspect 
ratio of the maximum image size is known, the ratio of the Maximum Size fields (H/V) should 
equal that aspect ratio, even if the maximum image size is unknown or variable across different 
device configurations (such as in a projection system). 


The following rules should be used in filling out the Maximum Image Size fields: 


a) Ifthe aspect ratio is known and the display size is known, then the actual size should be 
indicated, to the nearest cm. 


b) Ifthe aspect ratio is known but the size is unknown, any values corresponding to a typical or 
expected configuration of the display can be used, but the ratio of the Max Horizontal and 
Vertical fields shall be equal to the aspect ratio. 


c) Ifthe aspect ratio is unknown, or it is desired that it not be discoverable, then values of 0, O 
should be used. 


If the fields are set to zero, the Source should not make any assumptions regarding screen size 
or aspect ratio. 


In typical configurations, the image sizes described in each DTD (in bytes at offsets OxOC, OxOD, 
OxOE, in mm) should correlate to the values in the Maximum Size fields. For instance, a 160 cm 
by 90 cm display would indicate 1600 mm x 900 mm for all 16:9 Video Formats and 1200 mm x 
900 mm for all 4:3 formats. 


For example, data entry into the 0x15, 0x16 EDID bytes may be as summarized in Table 118. 
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Table 118 - Example 0x15, 0x16 EDID Screen Size Data and Certain Display Categories 


Category of Display EDID Physical Horizontal EDID Physical Vertical Physical AR to be calculated 
Screen Size (cm) Screen Size (cm) by the Source (unit less) 


Front Projector Typical dimension in cm Typical dimension in cm Source Divides H by V 
(enter either data row 
at option of implementer) Enter 0x00 Enter 0x00 AR is undefined 


0x17: Display Transfer Characteristics (Gamma) could be used by the Source to tailor the video 
output according the display device’s gamma. The concept of declaring gamma has to do with 
personal computer CRT displays that accept non-gamma corrected signals. Digital and analog 
television video signals are gamma corrected according to established industry practices and 
thus the need to declare CRT gamma is not always necessary. However, this is needed for 
Personal Computer CRT applications. Although the Source possibly may not need to use the 
display’s gamma value, the correct gamma value of the display device should be present. Since 
some television CRTs commonly have similar gamma, the value 2.2 is used in this example. The 
gamma value, itself, is not inserted into the table. Instead, a value equal to (gamma x 100) - 
100 is inserted. 


0x18: Feature Support consists of 8 bits that identify various display or Sink parameters. These 
include power savings modes based upon VESA Display Power Management Signaling Standard 
(DPMS), Display Type, Standard Default Color Space, Preferred Timing Mode, and Default 
Generalized Timing Formula (GTF). In most cases, none of this information is relevant to CE 
devices and personal computer displays, since GTF is not commonly used. In Table 119, the 
function of each bit is indicated. 
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Table 119 - Feature Support Detail 


[Bits | Feature | Description 
O = not supported 

Aa cai <->" ~ 
= not euppomtes 

pf octagon 
= not SUpPOMed 


Display Type (4:3) 


1 _ Undefined 

Non-RGB Display 
RGB Display 
Monochrome Display 


Color Space = a: supported, 
= not supported 
Preferred Timing 1 = preferred timing is indicated in first 


detailed timing block (required), 
= not indicated (not allowed) 


Default GTF “a GTF supported, 
= not supported 


The minimum that a CE device should declare is Display Type and Preferred Timing. In this 
example, Ox0A is used to designate a RGB display type and a preferred timing descriptor. The 
preferred timing descriptor bit shall be set to one and address locations 0x36 through 0x47 
shall contain the Preferred Format for only legacy Sources, as preference-by-location has been 
deprecated in favor of the VFPDB (Section 7.5.12). No other data is allowed in those locations. 
Source implementers are advised to follow guidance provided in Section 7.2.2. 
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Table 120 - Basic Display Parameters and Features Block 
ter [were een 
Hex Hex Dec 
Video Input Definition Example indicates: 
Digital; 
VESA DFP1X: not compatible 


0x15 0x50 Max. Horizontal Image CRT devices should list 

Size in cm parameters. However, due to 
projector and auto sizing 
devices, the system should not 
make any assumption regarding 
display size if data not supplied. 
This example indicates a 16:9 
aspect ratio device. 


0x16 Ox2D 45 Max. Vertical Image Size Optional; See above; This 
a incm example indicates a 16:9 aspect 
ratio device. 
100 = value (2.2 x 100)-100 = 120 


0x18 Ox0A 10 Feature Support Example indicates: 
RGB color Display type; 
Preferred timing: first detailed 
timing block; 
GTF timing: not supported; 
Standby mode: not supported; 
Suspend mode: not supported; 
Active off: not supported 


A.2.7 Color Characteristics 


Color Characteristics provides information about the display device’s chromaticity and color 
temperature parameters (white temperature in degrees Kelvin). 


Table 122 shows EDID addresses 0x19 through 0x22, which contain data used to describe 
various chromaticity characteristics; this example uses 9300° K as the white color temperature. 
These characteristics are represented by 10-bit binary fractions. Bits nine through two of a 
particular characteristic are stored as a single byte in addresses 0x1B ~ 0x22. Bits one to zero of 
that corresponding characteristic are paired with the lower order bits of other color 
characteristics to form bytes and are stored in addresses 0x19 ~ Ox1A. Table 122 shows the 
arrangement of these fractional binary values by EDID address. In the E-EDID standard, a 
decimal fraction such as 0.625 is represented by a 10-bit binary value. Each of the bit positions 
from left to right in the binary value represent powers of 2 from 27? ~ 27°. Table 121 illustrates 
an example decimal to binary conversion used for these color characteristics. Further 
explanation can be found in VESA E-EDID [9] Section 3.7. 
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Table 121 - Binary to Decimal Conversion Example 


10-bit Binary 
0.625 1010000000 0.625 


0.340 0101011100 0.33984375 
0.155 0010011111 0.1552734375 


How the table is filled is dependent upon the setting of address 0x18 in the Feature Support 
section. If sRGB is selected, then all values should be set in accordance to sRGB definition. For 
displays not supporting the sRGB definition, the example in Table 122 is applicable. 


Table 122 - Color Characteristics Block 


ine tL 
Hex Hex Dec 

00001101 

11001001 

10100000 

01010111 

01000111 


10011000 
00100111 
00010010 
01001000 
01001100 


NOTE — This data based on a CRT Display with a white point of ~9300° K (X = 0.283; Y = 0.298) 


Multiple white points can be specified using the Color Point Monitor Descriptor. However, 
there is no way to correlate to the individual Video Formats. Therefore chromaticity specified in 
Block 0 should be associated with the display device’s characteristics; however the White Point 
data does not. The Source should not rely on the colorimetry information contained in this part 
of the EDID data structure for CTA-861 formats. This recommended practice suggests the 
Source use the colorimetry that has been associated with the format in CTA-861 when possible. 
Note that this may not be possible because the Source probably just passes on the video 
stream. 
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A.2.8 Established Timings 


In the example in Table 123, addresses 0x23 through 0x25 are used to declare Established 
Timings. Established Timings are computer display timings recognized by VESA. This table is also 
used to indicate that the established timings were adjusted and verified at the factory, which 
means these timings are supported and correctly rendered on the display. 


In the example, Table 123, address 0x23 contains the default 640x480p timing and the 
remaining addresses are not used to list any other timings. Personal Computers, DVI-1.0 [4], 
Open LDI [8], CTA-861 require 640x480p as a default timing format. This is to ensure that all 
Sources and Sinks commonly support one format. Established Timings cannot be used as 
Preferred Video Formats unless they are duplicated elsewhere in the EDID and are 
representable by an SVR in the VFPDB (Section 7.5.12). See VESA E-EDID Section 3.8.1 [9] fora 
list of possible formats. 


Table 123 - Established Timings Block 


Address Example Data Description 
Hex Hex Dec 


Established Timing 1 640x480 @ 60Hz 


}ox24 | ox00 | 0 Established Timing 2 None 
pox25 L oxoo_ 0 Manufacturer's Timing 


A.2.9 Standard Timing ID #1 —8 


Standard timings are those either recognized by VESA through the VESA Discrete Monitor 
Timing or Generalized Timing Formula standards. The display device should list timings 
supported. The address range for this portion of the example EDID table is 0x26 through 0x35 
and the data length is two bytes. 


Since CE devices possibly may not support, other than the required 640x480p format, any of 
the VESA timings or GTF, the example in Table 124 does not contain any timing information. 
When no timings are declared, it is necessary to fill each unused byte, of the byte pairs, with 
Ox01 as padding. Other padding values are not recognized. 
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Table 124 - Standard Timing ID Block 


Address Example Data Description 
Hex Hex Dec 


Standard Timing ID #1 PC Application 


Standard Timing ID #2 PC Application 
7 
Standard Timing ID #3 PC Application 


Standard Timing ID #4 PC Application 


Standard Timing ID #5 PC Application 


Standard Timing ID #6 PC Application 
eater Mee 
Standard Timing ID #8 PC Application 
sa¢ [oo err eee 


A.2.10 Detailed Timing Descriptor Block 


The detailed timing section is 72 bytes in length and can be divided into four descriptor blocks, 
which are each 18 bytes. In the following example, the address ranges for these four blocks are 
0x36-0x47, 0x48-0x59, Ox5A-O0x6B and Ox6C-0x7D. Each of these descriptors contains either 
detailed timing data (Detailed Timing Descriptor) or other specific types of data as described in 
the VESA E-EDID standard. 


The VESA E-EDID standard allows various descriptor sequences, combinations, or repetitions 
and Sources should handle descriptors that may appear in any order. The only prescribed 
constraint is that Detailed Timing Descriptors precede the two required Monitor Descriptors in 
Block 0. The descriptors require the presence of valid data and no fill patterns are permitted in 
Block 0. Therefore, the Source should handle these possibilities and requirements accordingly. 
Blocks used for data, not detailed timing information, have a five byte identifier header that is 
formatted as follows: 0x00, 0x00, Ox00, <Tag #>, Ox00. For more detail regarding 18-byte 
descriptor tags, please refer to the VESA EDID standard section 3.10.3 [9]. 


The example in CTA-861 configures the four blocks in this order: First Detailed Timing 
Descriptor, Second Detailed Timing Descriptor, First Monitor Descriptor (Monitor Name), and 
Second Monitor Descriptor (Monitor Range). 


A.2.10.1 First Detailed Timing Descriptor 


The VESA E-EDID Standard [9] requires that the First Detailed Timing Descriptor be used for the 
most “preferred” Video Format and subsequent detailed timing descriptors are listed in order 
of decreasing preference. Due the complexities of new features in CTA-861 beyond the scope of 
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the E-EDID Standard, Video Format preference-by-location has been deprecated and preferred 
Video Formats are listed in the VFPDB (Section 7.5.12). However, legacy devices may still 
consider the first DTD in Block O and/or the first SVD as preferred formats. 


Data locations within the Detailed Timing Descriptors are used to specify the Video Timing 
characteristics, image size, and contain flags for identifying interlaced/non-interlaced formats 
and sync signal polarities. Designers of Source and Sink need to carefully consider these types 
of data in all implementations. 


The example in Table 125 shows the data format for a Preferred Video Format of 1920x1080i 
and the image size is matched to the screen size of approximately 36 inches diagonal. CTA-861 
recommends listing exact horizontal and vertical dimensions, but at least requires values that 
describe the aspect ratio. The Source should be capable of using these dimensions to determine 
aspect ratio. However, some EDID implementations that do not provide horizontal and vertical 
dimensions for non-CTA-861 Video Formats may be encountered. The flags are set to convey an 
interlaced format and the syncs as separate and of positive polarity. 


Table 125 - First Detailed Timing Descriptor Block (1920x1080i Example) 


Address Example Data Description Remarks 
en [her bee et peterto note beow for ational ets) 


|Ox3A | O71 113 | HActive:HBlanking | 
Ox3D_ | 0x20, | 32 | VActive:VBlanking | 
Ox3F_ | Ox2C_— 1 44 | HSyncPulseWidth | 44 pixels 
0x41 0x00 HS Offset: HS Pulse Width: 
ef Lo [ieoreeevspusewi | 
ef RRs eraneorvse 
i 4 bits of V Size: 
}Ox45 | OOO, | OH Border pixels 
ox46 | x00 | 0 Border id ines @ 


0x47 Ox9E 158 Flags Interlaced, normal display no stereo, digital 
separate, Vsync polarity is positive, Hsync polarity 
is positive 


Note: Some addresses above contain “composite” bytes representing high and/or low order bits or “nibbles” (4 bits 
of an 8-bit byte). Please refer to Section 3.10.2 of the VESA E-EDID standard for details on these fields. 
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A.2.10.2 Second Detailed Timing Descriptor 


Table 126 contains an example for the second preferred timing using the Second Detailed 
Timing Descriptor block. This is the SDTV 720x480p format that has a 4:3 aspect ratio. 


Table 126 - Second Detailed Timing Descriptor Block (720x480p, 4:3 Example) 


Address Example Data Description Remarks 
ten [wer oee | P| freer to note below fr ado detais) 
oxac | ox20. | 32, | HActive:HBlanking | 
Ox4F | Oxt0, | 16 | VActive:VBlanking | 
0x53 0x00 HS Offset: HS Pulse Width: 
PLL isorecvspusewity | 
0x56 Ox21 33 H&V Image Size Upper 4 bits of H Size; 
eR mw iicramervsce 
(0x57 | oxo, [OL Border pixels CC 
(oxs8 | oxo, [OV Border limes 
0x59 0x18 24 Flags Non-interlaced, normal display no stereo, digital 
oe | Sate vcandt omepoareysnegstve 
Note: Some addresses above contain ‘composite’ bytes representing high and/or low order bits or “nibbles” (4 bits of an 8- 
bit byte). Please refer to Section 3.10.2 of the VESA E-EDID standard for details on these fields. 


A.2.10.3 First Monitor Descriptor (Monitor Name) 


The VESA Standard [9] requires that one of the four 18-byte descriptors be a Monitor Name 
Descriptor. Here, it is recommended that the third 18-byte descriptor be used as the First 
Monitor Descriptor or Monitor Name. Examples of these bytes are located at addresses Ox5F 
through Ox6B. Each location is one byte in length and is used for ASCII character string. In the 
example contained in Table 127, a fictitious Monitor Name is listed. 
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Table 127 - First Monitor Descriptor Block (Monitor Name) 


Address Example Data Description 
ross foo pe eer 
(oxsB sf x00, = [OT descriptor 
Ox5C 0x00 Flag (Reserved) Flag = Ox00 when block used as 
ee ee ee 
Ox5D OxFC 252 Data Type Tag OxFC denotes that last 13 bytes of this 
rere ict bockcontan Monitor rae 
Ox5E 0x00 Flag Flag = Ox00 when block used as 
ee eet ee 


ASCII coded monitor Example monitor name: 
0x60 | 0x59] 89 name (13 bytes max). 

“MY HDTV” 
fname < 13 bytes, 

} 0x63 si /0x44 =| 68 eee as ay . 

ox64 =i“ «sf x4 Sf 4 xOA and fill remainder o 

oe eee ee 13 bytes with 0x20. 


A.2.10.4 Second Monitor Descriptor (Monitor Range Limits) 


The next and last 18-byte descriptor within Block 0 should be used as the Second Monitor 
Descriptor. In this example, it is the Monitor Range Limit, which is used to designate minimum 
and maximum parameters for horizontal and vertical frequencies and maximum pixel clock 
rate. In the following example, the block of data ranges from Ox6C through Ox7D. The data 
format is binary coded integer. 


The first three locations, Ox6C (Flag), Ox6D (Flag), and Ox6E (Reserved Flag) are set to zero. 
Address Ox6F, a Data Type Flag, should be set to OxFD, which means, “monitor range limits, 
binary coded.” For more detail, please refer to the VESA E-EDID standard Section 3.10.3 [9]. 
Address 0x70 is another flag and loaded with zero. 


Locations 0x71 through 0x75 are used to designate the minimum and maximum parameters for 
horizontal and vertical frequencies, and maximum pixel clock. Table 128 contains an example 
for a DTV that supports a 60 Hz vertical refresh rate, 15 kHz up to 46 kHz horizontal rates, which 
cover the frequencies required for 720x480i, 720x480p, 1280x720p and 1920x1080i formats 
having a maximum pixel clock of 80 MHz. 


For EDID (Version 1, Revision 3), inclusion of the Monitor Range Limits in EDID Block 0 does not 
imply that the Sink is multi-scan capable 


Note: To reduce the possibility that a Source would mistakenly ignore the frequency 
range data if the minimum and maximum values were equal, a range of horizontal and 
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vertical frequencies should be declared. For example, if a device supports only 15.75 kHz 
and 60 Hz timing, it is recommended to list the range as 15 to 16 kHz and 59 to 61 Hz. 
Sources may encounter legacy devices that specify the same value for MIN and MAX 
horizontal and/or vertical ranges. 


Table 128 - Second Monitor Descriptor Block (Monitor Range Limits) 


fer were [Pn 
Hex Hex Dec 

}oxec =——s«s| x00 «SOC Flag Flag = 0x0000 when block used 
pox6D | Ox —| 0 as descriptor 


Ox6E 0x00 Flag (Reserved) Flag = Ox00 when block used as 
descriptor 


Ox6F OxFD 253 Data Type Tag FDh denotes that last 13 bytes 
of this descriptor block contain 
Monitor Range limits, binary 
coded 
a al A in AO Fl 
descriptor 


|Ox74 | Ox2E_ | 46 | MaxHorizontalRateinkHz | 46 KHz 


TE amen teetmtsecsn [OME 

MHz/10 

ee ee 
(OxOO=not used) supported 


Put OxOA after last data byte in Unused data address 
block and fill remaining bytes with 
32 O20) 


Address 0x76 is used as a tag for a secondary generalized timing formula (GTF) and is not 
typically used for CE devices. In this case, the flag is set to zero. Addresses 0x77 through Ox7D 
are related to this tag. The E-EDID standard requires that address 0x77 contain OxOA and 
addresses 0x78 ~ Ox7D contain 0x20 when no secondary GTF data is provided. 


A.2.11 Extension Flag and Checksum 


The Extension Flag and Checksum are defined as two-byte data located in address range Ox7E 
through Ox7F. The Extension Flag is used to indicate that additional blocks are present in the 
EDID that declare additional Video Formats and other monitor features. 


The Extension Flag is used to declare the number of extensions that exist within the EDID 
tables. The total number of extensions actually present should equal the number of extensions 
declared within Block 0. The number of extensions declared in Block O shall exclude Block O 
itself, but shall include any Block Map Extension. For example, if no extensions exist in the EDID 
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data, then the Extension Flag shall be set to zero. If a single (e.g., CTA) extension is present, 
then the flag shall be set to one. If two (e.g., CTA) extensions are used, then a block map 
extension is also required by VESA EDID standard — increasing the total number of extensions 
to three. In this case, the extension flag is set to 3 and the Sink has an EDID containing a total of 
four 128-byte blocks: Block O plus three extensions — the first extension being a block map. 


Note: Some devices have been incorrectly designed so that the block map is not 
counted in the extension count. Design of compliant devices should take compatibility 
with those non-compliant devices into consideration. For example, when a Source finds 
an extension count of 2, it may attempt to read 3 extensions on the chance that the Sink 
has incorrectly set its count, or it may use the information in the block map as a more 
accurate guide. 


The Checksum is set so that the sum of the entire 128-byte block modulus 256 equals Ox00. Sink 
designers should calculate checksum using the following formula: 


Checksum byte = (256-(S%256)) %256 
Where: 
S is the sum of the first 127 bytes 
% is modulus operator 


Table 129 contains example data based upon the tables presented in CTA-861. The Extension 
Flag at location 0x7E is set to one declaring that Block 1 is present. Since the Extension Flag 
equals 1 in the example, no other blocks exist. The Checksum is set so that the sum modulus 
256 of the entire 128-byte block equals Ox00. 


Table 129 - Extension Flag Block 


Address Example Data Description 
Hex Hex Dec 


follow 
= 0x1B3D 


A.2.11.1 Block One Details 


Although there may be DTV implementations that do not include a CTA Extension or that 
include it in a block other than Block 1, it is recommended that for a CTA-861 implementation, 
that the CTA Extension be included in Block 1. Therefore, the remainder of Annex A (through 
Section A.4) assumes that Block 1 is a CTA Extension. 


One purpose of the CTA Extension is to provide a place to add additional Detailed Timing 
Descriptors. However, other VESA-defined 18-byte descriptors are possible (e.g., Monitor Serial 
Number, Manufacturer Specific, etc.). Sources should ignore descriptors that they do not 
understand. The only descriptors that a CTA-861 Source is required to understand are the 
Detailed Timing Descriptors, the Monitor Range Limit descriptor, and the Monitor Name 
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Descriptor. Note that the handling of unused descriptors is different in the CTA Extension than 
it is in Block 0. In Block 0, all four descriptor blocks are required by VESA EDID standard [9] to be 
filled with valid data, even if it means repeating a timing descriptor. In the CTA Extension, 
unused descriptor locations are all collected at the end and filled with a fill pattern of 0x00. 
Technically, a descriptor that has the first bytes being 0x00 would be a manufacturer-defined 
descriptor with a tag of OxO0. It is recommended that manufacturers avoid the use of a Ox00 
tag. Sources should verify that there are eighteen 0x00 bytes following the last valid descriptor 
if there is enough room for a descriptor. It is also recommended that the DTV place all of its 
remaining Detailed Timing Descriptors before other descriptors in the CTA Extension. 


Within the CTA Extension, per CTA-861, up to six Detailed Timing Descriptors are allowed and 
may occur in any order. Therefore, Sources should be able to handle any combination or 
sequence that these Detailed Timing Descriptors may appear. According to CTA-861, any of 
these DTDs may be indicated using SVRs in a VFPDB (Section 7.5.12). Sources should be capable 
of skipping additional extensions that they may not understand when encountered within Block 
1. 


A.2.12 Overview of Extensions 


VESA has assigned Extension Tags to identify EDID extensions and Sources should anticipate 
encountering some of these extensions. Extensions are identified by the first byte (i.e., Tags). 
The Tags indicate the type of extension and its purpose. CTA-861 implementations are required 
to use Tag = 0x02 for the CTA Extension Tag and Sources should ignore Tags that are not 
understood. 


In the subsequent sections of this Annex (excepting Section A.2.19), an example is given 
utilizing CTA Extension block version 1. Version 3 of the CTA Extension is most common and is 
required for HDMI implementations. For HDMI implementations, extension block version 3 is 
required. An example of version 3 is given in Annex D.6. See Section 7.1 for additional guidance 
on the use of specific versions. 


A.2.13 Block One CTA Extension Header 


The CTA Extension Header is defined as four-byte data located in the first four bytes of the EDID 
block. The first byte is the tag used to identify the extension. The number assigned by VESA to 
this tag is Ox02. Following the CTA Extension Tag is the Revision Number location. The data for 
Revision Number was set according to which standard version the Sink was designed to 
support. The January 2001 release of CTA-861, CTA-861-A, and CTA-861-B all had unique 
number assignments for the Revision Number and this was used to differentiate the level of 
supported features, such as “InfoPackets“, audio, etc. Beginning with CTA-861-C and continuing 
through present, incrementing the version number is no longer required. The revision number 
Shall be set to 0x03. 


Note that the January 2001 release of CTA-861 and CTA-861-A required the revision number to 
be set to 0x01 and Ox02, respectively. See Section 7.1 for further guidance. Versions 2 and 3 of 
the CTA Extension are backward compatible with version 1, which is illustrated in this example. 
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Sources should be prepared to read versions later than version 1 and properly interpret the 
required 18-byte descriptors. 


Following the Revision Number is the Byte Number Offset. This is used to tell where the 
Detailed Timing Data begins following the Reserved Data Block. The Source should use this byte 
offset to skip fields that it may not understand within the CTA Extension when encountering 
versions of this extension that may be newer than its own. CTA-861 Sinks should load location 
82 with d = 4 if the extension includes 18-byte descriptors. In the following example, the data is 
listed as Ox04, which means there is no data present in the Reserved Data Block and that there 
are 18-byte descriptors present starting at the fifth byte of the EDID block. 


Sources should be aware that for later versions of the CTA Extension, d may be set to 
something other than 0 when no 18-byte descriptors are present. This is an indication that 
there is data in the reserved data block. In such a case, d would be set to the location where 18- 
byte detailed timing descriptors would be located if present. That data should be skipped by a 
CTA-861 Source. The presence of padding data for 18-byte descriptors can be used by the 
Source as an indication whether 18-byte descriptors are present or not. 


The data at the next address location, 0x83 in this example, is reserved in the CTA Extension 
Version 1 (used for an 861 implementation) and is required in 861 to be set to 0x00. Newer 
versions of the CTA Extension include flags in this field (see Sections 7.3 through 7.3.3). These 
flags can be ignored by a CTA-861 Source. 


Table 130 contains example data based upon the tables presented in CTA-861. In this example, 
the CTA Extension Tag is located at 0x80 followed by Revision Number, Byte Number Offset, 
and Reserved (i.e., 0x00). The data is set as prescribed by CTA-861. 


Table 130 - Block One CTA Extension Header 


Hex Hex Dec 
for fils extension 
by this device 


all lanl 0x04 per CTA-861 0x04 indicates no data present in 
Reserved Data Block; 18-byte 
descriptors ARE present 


0x83 0x00 Ox00 per CTA-861 These bits are utilized as flags in 
later versions of CTA-861 


A.2.14 Third Detailed Timing Descriptor 


Following the Extension Flag Table is the next or Third Detailed Timing Descriptor. Table 131 
follows the same format as with Table 125 and Table 126. This example is for HD format 
1280x720p. 


170 


CTA-861-H 


Table 131 - Third Detailed Timing Descriptor Block (720p, 16:9 Example) 


Address Example Data Description Remarks 
fener pee | eterte note below ational dts) 


poxse | x00 | OH Active | 1280 pixels 

oxss | 0x52 | 81 | HActive:H Blanking | sd 

(0x88 | 0x20 | 32 VActive:VBlanking | 

|Ox8D | 0x28 | 40 | HSyncPulse Width | 40 pixels 

Oxse | OSS | 85 | VS Offset: vSPulseWidth | 
Ox8F 0x00 HS Offset: HS Pulse Width: 

OO 8 [eoimeevseusewet | 
0x92 0x31 H&V Image Size Upper 4 bits of H size; 

a a ca Becht 

pox93 | x00 “JOH Border pixels 

poxo4 | x00 OV Border sd limes 


0x95 Ox1E 30 Flags Non-interlaced, normal display no stereo, 
digital separate, H and V sync polarity is 
positive 


Note: Some addresses above contain ‘composite’ bytes representing high and/or low order bits or “nibbles” (4 bits 
of an 8-bit byte). Please refer to Section 3.10.2 of the VESA E-EDID standard for details on these fields. 


A.2.15 Fourth Detailed Timing Descriptor 


After the Third Detailed Timing Descriptor, the next Detailed Timing Descriptor follows, as 
indicated in Table 132. As with Table 125, Table 126 and Table 131, the same format is used. 
This table declares the SD 720x480i format, which requires doubling the horizontal pixel count 
to meet the DVI 1.0 minimum pixel clock frequency. 
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Table 132 - Fourth Detailed Timing Descriptor Block (480i, 4:3 Example) 


Hex Hex Dec (Refer to note below for additional details) 
|Ox9A | OxS1 | 81 HActive:H Blanking | Ci 
ox9D | Ox00 [0 Active: Blanking | 
|OxAO | 0x43 | 67 | VS Offset: VSPulseWidth | 
OxA1 0x00 HS Offset: HS Pulse Width: 
OPP TS [soreevvsousewen | 
oR Pie ieerapuarvsce 
co 4 bits of V Size 
|OxAS | OOO | OH Border limes 
|oxAG | 0x00 [Os Border Cd pixels 
V. and H. sync polarity is negative, 
Note: Some addresses above contain ‘composite’ bytes representing high and/or low order bits or “nibbles” (4 bits of an 
8-bit byte). Please refer to Section 3.10.2 of the VESA E-EDID standard for details on these fields. 


A.2.16 Descriptor Defined by Manufacturer 


The Descriptor Defined by Manufacturer Table is placed after the last Detailed Timing 
Descriptor. The manufacturer defines the contents of this descriptor. The tag can be any value 
between 0x00 and OxOF although the use of 0x00 is not recommended as explained in Section 
A.2.11.1. The example in Table 133 illustrates data that declares a revision number. 
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Table 133 - Descriptor Defined by Manufacturer Block 


Address Example Data Description 
ter [wore [een 
OxAs_ | Oxo] Of lng Cid 
oxa9 | Oxo] lng | Cid 
|OxAA | 0x00] 0 Reserved | Cid 
|OxAB | OxO1, =f 1 | (DataTypeoi-or | Cd 


A.2.17 Monitor Serial Number 


13 bytes of this 18-byte table are allocated for the Monitor Serial number. This table can be 
used for the manufacturer’s convenience. The monitor serial number descriptor uses OxFF as 
the tag. Tags are described in Section 3.10.3 of VESA E-EDID [9]. The data should be ASCII 
based. Table 134 contains a fictitious serial number as an example. 
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Table 134 - Monitor Serial Number Block 


Address Example Data Description 

iene | OO 
rosso fo] eer omteenbierkweteeceerer 
|OxBB_ | Ox00 =| OC 


}OxBC «| Ox0O «6 OCC Flag (Reserved) Flag = Ox00 when block used as descriptor 


OxBD OxFF 255 Serial Number Tag Refer to VESA E-EDID standard, Section 3.10.3 
for tag definitions 


pOxBE | oxoO, | Od Flog 
ASCII serial number data coh 
poxc4 | O30 48 

poxcs | O30 48 

joxce | O30 48 

poxc7 | O31 4 


A.2.18 Residual Byte Padding and Checksum 


CTA-861 requires that residual addresses contain padding. In this case, Ox00 is used as padding. 
Address OxFF should contain a one-byte checksum value such that when all bytes of the entire 
128-byte block are added, the sum modulus 256 equals Ox00. Table 135 illustrates these 
requirements. 
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Table 135 - Residual Byte Stuffing and Check Sum Block 


Address Example Data Description 
Hex Hex Dec 


poxcc | x00, =| OA padding byte 
}oxcD  —« {| oxoo0 «OO Padding bytes should = 0x00. 
FoxcE —s« | oxoo «So[OCCCCSY Additional padding bytes 
poxcr | Oxo FO 
|oxdo_ | x00, SFO 
|Oxb1 | oxoo =f 
pOxo2 | OOOO 
|oxo3 | x00 SFO 
|Oxb4 | x00 FO 
pox05 | x00 SFO 
|oxde | x00, SFO 
|oxo7_ | x00, SFO 
pods | OOOO 
|oxo9 | x00 FO 
|OxDA | x00, SFO 
|oxoB | x00 SFO 
poxoc | x00, =f OT 
poxoD | ooo OO 
|OxdE | x00, SFO 
|OxOF | Oxo, FO 
|Oxeo | x00, FO 
pOxeL | x00, FO 
|Oxe2 | x00 SFO 
pores | OOOO 
|Oxea oxo F OT 
pOxes | x00, FO 
poxe6 | x00} OT 
|Oxe7 Oxo, SFO 
pores | OOOO 
|oxeo | x00 FO 
|OxEA | x00, SFO 
pOxeB | x00, FO 
pOxec | x00 FO 
pOxeD Oxo, =} 
pOxeE | OOOO 
pOxeF | x00, FO 
|OxFo | oxo =f 
pOxFa | x00 FO 
pOxF2 | oxo =f OT 
pOxF3 | OOOO 
jOxFa | oxo FO 
pOxF5 | x00 F OT 
poxF6 | x00, FO 
|OxF7 | x00 FO 
a 
pOxFg | oxo FO 
|OxFA | x00 FO 
pOxFB | Oxo =| OT 
pOxFc | oxo | OT 
|OxFD | x00 =| OT 
|OxrE | OOOO Last padding byte 
Block 1 sum (address 0x80~OxFF) = OxOE7C 
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A.2.19 Hot Plugging Sequence 


An important element to proper interpretation of EDID is “Hot Plugging”. The following 
presents a recommendation for achieving consistent results during a Hot Plugging event. 


DVI 1.0 defines a Hot Plug Detect (HPD) signal function that indicates to the Source whether a 
display is connected. HPD is designed to be powered by the DDC + 5V coming from the Source, 
and to be independent of whether the monitor is powered or not. In this way, a Source can 
detect the monitor and read its characteristics from EDID without the monitor being powered. 
On a PC, this feature allows the system to load the correct display configuration without 
delaying the boot process. 


In short, in this context, HPD serves as an indication that the EDID is available to be read, 
however HPD may also have alternative uses. It does not imply any other state of readiness. 
The relevant definitions from the DVI 1.0 specification are: 


a) Section 2.6: Hot Plug Detect (HPD) — Signal is driven by monitor to enable the system to 
identify the presence of a monitor. 


b) Section 2.2.9.2: The monitor is required to provide a voltage of greater than +2.4V on the 
Hot Plug Detect (HPD) pin of the connector only when the EDID data structure is available to 
be read by the Source. 


Implementation Note: As an example for hot plug support, a simple monitor implementation of 
HPD support could be a pull up resistor to the EDID power supply. After HPD goes active, the 
Source is only expected to read EDID and determine that a valid display mode is available and 
supported. 


Note: Whenever the EDID information in a device changes for any reason (e.g., if the 
EDID was updated, or is capable of dynamically changing its information content), the 
receiving device pulses HPD low for at least 100ms. This recommendation follows from 
the HDCP repeater implementation requirement that HDCP repeaters pulse HPD low for 
at least 100ms to indicate the connection of a new device or disconnection of an 
existing one. 


A.2.20 InfoFrame Data Block 


An example InfoFrame Data Block is shown in Table 136. It is defined as an 11-byte data 
structure located in the CTA Data Block Collection. The first byte is a tag used to identify the 
data block as extended along with its payload length. The second byte identifies the extended 
data block as an InfoFrame Data Block. The tag/length and extended type bytes are followed by 
an InfoFrame Processing Descriptor, which indicates that up to 4 VSIFs may be received 
simultaneously. Short InfoFrame Descriptors follow the InfoFrame Processing Descriptor in 
order of priority. In this example, support for THX Auxiliary VSIF, NTSC VBI, and SPD InfoFrames 
are indicated. The highest priority is the THX Auxiliary VSIF, while the lowest is the SPD 
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InfoFrame. By convention, Interface VSIF remains a higher priority than the THX VSIF, however. 
The Short InfoFrame Descriptors are described in Section 7.5.9. 


Table 136 - InfoFrame Data Block (Example) 


Address Example Data Description 
Hex Hex Dec 


OxBB 0x20 32 InfoFrame Data Block. 0x20 = InfoFrame Data Block Extension Tag 
Extended Tag Code 
bal ll 


OxBF 
OxCO 
OxC1 
OxC2 
OxC3 


250 
oxoo [OL 


a 


Start InfoFrame data block. 
Indicates Extended Tag 
Code and length of 
following data block 
payload 


InfoFrame Processing 
Descriptor 


Short Vendor-Specific 
InfoFrame Descriptor 


Short InfoFrame Descriptor 


Short InfoFrame Descriptor 
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OxEA = Extended type block (code = 7) and ten 
bytes of data payload 


only header present. 
addition to the first for a total of 4 


Supports the indicated VSIF InfoFrame (code=1) 
and one extended VSIF description byte — 
therefore header plus one byte of extended 
description. 

THX Identifier = 0x0012FA (The big-endian THX's 
24-bit OUI Registration Identifier Ox0012FA is 
placed into the EDID in little-endian order.) 


THX’s Extended VSIF Description 


Supports NTSC VBI InfoFrame (code=6), Zero 
bytes of extended description — therefore only 
header present. 

Supports SPD InfoFrame (code=3) 

Zero bytes of extended description — therefore 
only header present. 
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A.3 Complete Example EDID Table (Informative) 


Table 137 - Complete EDID Example 


Address Example Data Name of Block Description 
Hex Hex Dec 


rox00 | oxo0 | 0] Block Zero Header —_ Fixed Value 


0x07 | x00 =| 0 

}Ox0A «| 0x00 =f OO Product Code Used to differentiate between 
Ox0B 0x00 different models from the 

on ee Fe same manufacturer. 

/Oxoc «| Ox00 =f OO Serial Number Optional. 

/Ox0D —«| Ox00 =| 00 The serial number can also be 

}OxOE —«| Oxo =| CO-C*" stored in a separate descriptor 

|Ox0F | 0x00 | 00 pee 


0x10 0x00 Week of Manufacture Optional. 
If this field is unused, the value 
should be set to O. 


Year of Manufacture Year 2002 
EDID Structure Version / 
Revision 


0x14 0x80 128 Basic Display Parameters / Video Input Definition Digital, VESA DFP1X : not 
Features compatible 


0x15 0x50 Max. Horizontal Image Size | Optional. 
incm The system should not make 
any assumption regarding 
display size 
cm See above. 
100 = value (2.2 x 100)-100 = 120 


0x18 Ox0A 10 Feature Support Ox0A denotes: 
RGB color Display type, 
preferred timing: first detailed 
timing block. GTF timing: not 
supported. Standby mode: not 
supported, suspend mode: not 
supported, active off: not 
supported 
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Table 137 - Complete EDID Example (continued) 


Address Example Data Name of Block Description 
Hex Hex Dec 


13 Color Characteristics | Red/GreenLowBits | 
| Blue/WhiteLowBits | 


0.298 
Established Timings 640x480 @60Hz 


|Ox24 | x00 | OT 


0x25 0x00 Manufacturer's Reserved None 
ee Ting eee ee 
ID #1-8 
(Preferred) 
| HActive:HBlanking | Cd 
| VActive:VBlanking | Cid 
| Ox3F | Ox2c | 44 
0x41 0x00 HS Offset: HS Pulse Width: VS 
La Nall cl [onecvsrusewarn | 
| Oxa4 | O32 49 PH&VImageSize | CC—“‘“‘C;C*SCSCsCS 
| Ox45 | Oxo OC 
| ox46 | Oxo JO 


H Blanking 280 pixels 
VS Offset: VS Pulse Width 2 lines, 5 lines 
0x47 Ox9E 158 Flags Interlaced, normal display no 
stereo, digital separate, Vsync 
polarity is positive, Hsync polarity 
is positive 
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Table 137 - Complete EDID Example (continued) 


Address Example Data Name of Block Description 
ter [herpes [eee feet 
Descriptor 


| HActive:HBlanking | 

|VActive:VBlanking | 

oe eee [wsorservspusewan [| 
VS Offset: VS Pulse Width 

|H&VImage Sie | 


/0x57_ | 0x00 | OL 


/0x58 | 0x00 | 0 


0x59 0x18 24 Flags non-interlaced, normal display 
no stereo, digital separate, V. 
and H. sync polarity is negative 


}OxSA ss | Ox00 «| OC Monitor Descriptor Currently | Flag 
}0x58 | 0x00 | 0 __| Mandatory 


/OxsC | 0x00 | 0 | (Monitor Name) |Flag(Reserved) | 
|OxSE | 0x00 | OT a 
et ___sf 
/Ox60 | 0x59 | 89 a 
EE 
et 
0x63 | 0x4 | 68 es ee 
|Ox64 | 0x54 | 84 

0x65 | 0x56 | 86 St 
a) (es 
rr 
rs 
aa 
re | D 
a (ees 
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Table 137 - Complete EDID Example (continued) 


Address Example Data Name of Block Description 
ter [hee ee eee ee 
| Ox6D —«| 0x00. =| O ~_}_ Currently Mandatory 
|Ox6E | 0x00 | 0 _—| (rangelimits,binarycoded) | Flag(Reserved) | 
Ox6F OxFD 253 Data Type Tag Monitor Range limits, binary 
baal eae Lal Paarwrere | Segedsmanisto ck 
|0x70 | Oxoo | OT aa | 
59 HZ 


Min Horizontal Rate in kHz 15 kHz 
| 0x74. sf Ox2E. =| 46 Max Horizontal Rate in kHz | 46 kHz 


Ox75 0x08 Max Supported pixel clock 80 MHz 
Liesl ell bal acinus fe 

0x76 0x00 Tag for secondary timing No secondary timing formula 
Fixed 
Fixed 
Fixed 
Fixed 
Fixed 
Fixed 
Fixed 


Ox7E Ox01 1 Extension Flag Number of 128 bytes blocks 
to follow 


CTA Extension Header 
|Ox82_ | x04 | a 
Loxg3_ | x00 fo LOxooby861 
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Table 137 - Complete EDID Example (continued) 


Address Example Data Name of Block Description 
Hex Hex Dec 
Third Detailed Timing Pixel Clock 74.25 MHz 


Descriptor 


|oxse | oxoo_ [oO 
| HActive:HBlanking | 
|VActive:VBlanking | 
ox8D_ | 0x28 | 40 
[VS Offset: VSPulseWidth | 
a [wsorservsrusewan [| 
VS Offset: VS Pulse Width 
|ox92 | 0x31 [| 49 H&V Image Size ) 


/0x93 | 0x00 | OT 
/0x94 | 0x00 | OT 


Fourth Detailed Timing 
Descriptor 


H Border 
V Border 


Non-interlaced, normal display 


Flags 
no stereo, digital separate, H 
and V sync polarity is positive 


Pixel Clock 27 MHz 


H Active 
H Blanking 
H Active: H Blanking fs 
V Active 
V Blanking 
|ox9D | ox00 | OT V Active: V Blanking ee 
H Sync Offset 
H Sync Pulse Width 
VS Offset: VS Pulse Width 
aie | HS Offset: HS Pulse Width: 

VS Offset: VS Pulse Width 
H Image Size 
V Image Size 
H&V Image Size 
|OxA5 | ox00 | 0 H Border 
/Oxa6 | Ox00 | OT V Border 


interlaced, normal display no 
stereo, digital separate, V. and 
H. sync polarity is negative, 


Flags 
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Table 137 - Complete EDID Example (continued) 


Address Example Data Name of Block Description 
Hex Hex Dec 


|OxA8 | 0x00__| 0__| Descriptor Defined by Flag 
|OxA9 | 0x00 | 0 Manufacturer Flag 
|OxAA | ox00 | 0 pReserved | 
| DataTypeOxo1-oxoF | 
|OxAC | x00 | 0 a 
POxAE | 0x45 | 69 € 

|OxAF | 0x56 | 86 V 

/OxBO | Ox31_ | 49 ae (ce 
/OxB1 | Ox2E_ | 46 a 
/OxB2_ | 0x30 | 48 ae (es 
/OxB3 | 0x30 | 48 OO 
ea |e 
/OxB5 | x00 | OO EE ee 
/OxB6 | x00 | 0 See 
|OxB7 | x00 | OO 

|OxB8 | x00 | OO 

/OxB9 | x00 | OO 

/OxBA «| Ox00 «6 {OC Monitor Serial Number 

|OxBB | 0x00 | O__| (ASCII, 13 bytes max) rs 

poxec_ | oxoo [Oo pO 

/OxBE | x00 | OO Be 

}Oxco. —s- | 0x39. | 57 

|oxc4 | 0x30 | 48 

poxcs | 0x30_— | 48 

poxcé | 0x30_—| 48 

|Oxc7 | Ox31_ | 49 
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Table 137 - Complete EDID Example (continued) 


ccd oa Residual Byte Padding 
poxcD | oxo | 
|OxcE | Oxoo | 
|OxcF | Oxoo | 
|Oxd0_ | x00 
|Oxd1 | oxo 
|Oxd2_ | oxoo | 
(OxD3_ | x00 
|OxD4 | oxoo | 
|Oxds | oxo | 


/OxD6 | oxoo | a Se 
|Oxd7_ | 0x00, | aa |e 


|Oxos {| oxo 
|Oxo9_ | ooo | OO 
|OxDA | oxoo | OT 
|OxDB | oxoo | OT 
|oxoc | oxoo | OO 
|OxDD_ | ooo | OO 
|OxDE | oxo 
|OxDF_ | oxoo = | OT 
|OxeO | ooo | OO 
/OxeL | oxoo | 
/OxE2 | Ooo =| OO 
|Oxe3 | Ooo | OO 


/Oxe4 | oxoo | O ea 
pOxeS | 0x00, | OO Pe _________ 


|Oxes | Oxoo 
|Oxe7 | Oxoo | OO 
|Oxes | Ooo | OO 
|Oxe9 | oxoo 
|OxEA | Oxoo | OT 
|OxeB | Oxoo | OO 
|OxeC | oxo 
|OxED | ooo | OO 
|OxeE | Ooo | OO 
/OxeF | oxoo | 
|OxFO | oxoo | OO 
|OxF1 | ooo | OT 


|OxF2 | oxo a | 
|OxF3 | 0x00, | OO ea |e 


OxFa | oxoo fo 
joxr5 | oxoo fo 
joxr6 | oxoo, fo 
|OxF7 | Oxon fo 
oxF8 | Oxon fo 
oxo | oxoo fo 
|OxFA | Oxon | Oo 
(oxrB | Oxon fo 
joxFc | oxoo fo 
|OoxFD | oxoo fo 
joxFe | oxoo fo 
LOxFE | oxga | 132_| Checksum | Block A sum = 0x0E7ZC 
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A.4 Example EDID Detailed Timing Descriptors 
Table 138 - Example EDID Detailed Timing Descriptor for 1280x720p (60 Hz, 16:9) 


Byte# Value Value 
(HEX) (HEX) (binary) 

Pixel Clock/10,000 (LSB stored first) Ee 2 | Pixel Clock = 74.25 MHz 
0x37 OxIp | 


Horizontal Active Pixels (lower 8 bits) OOo, ei hor. Active Pixels = 1280 = 0x500 
x72 | hor. blanking pixels = 370 = 0x172 


vert. Active Lines = 720 = 0x2D0 


0x39 | Horizontal Blanking Pixels (lower 8 bits) 
Ox3A | Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


Ox3B | Vertical Active Lines, lower 8 bits OxDO 
Ox3C | Vertical Blanking Lines, lower 8 bits 


QOx3D | Vertical Active: Vertical Blanking 


vert. Blanking Lines = 30 = Ox1E 
(upper nibble = upper 4 bits of active) 


(lower nibble = upper 4 bits of blanking) fo 
Ox3E | Horizontal sync. offset (pixels) offset = 110 pixels = Ox6E 
(from blanking starts, lower 8 bits) 


io) 


oO 
x 

On 
ke 


Ox3F | Horizontal sync pulse width (pixels) width = 40 pixels = 0x28 
(lower 8 bits) 


Ox40 | Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 


bits 7,6: upper 2 bits of Hor. sync. offset 00000000 
bits 5,4: upper 2 bits of Hor. sync pulse width 

bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


Horizontal Image Size (mm, lower 8 bits) Hor. Image size = 708 mm = 0x2C4 
QOx43 | Vertical Image Size (mm, lower 8 bits) Vert. Image Size = 398 mm = 0x18E 


0x44 | Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 


vert sync. offset = 5 lines 
vert. sync width = 5 lines 


Ox4 


Z 


Ox45 | Horizontal Border (pixels) Shall be 0 
Ox46 | Vertical Border (lines) Shall be 0 


Ox47 | Flags (bit 7 = non-interlaced; bit 5,6 = normal Ox1E O00 TI 10 Flag = non- interlaced; non-stereo; 
display; bit 1, 2, 3,4 = sync description; bit 0 = digital separate; positive V sync; 


do not care) positive H sync 


SS 
x 
oO 
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Table 139 - Example EDID Detailed Timing Descriptor for 1920x1080i (60 Hz, 16:9) 


Byte# Value Value 
ten een) [ary 
| oxtD | 


Horizontal Active Pixels (lower 8 bits) | oxso | ss hor. Active Pixels = 1920 = 0x780 
0x39 | Horizontal Blanking Pixels (lower 8 bits) | shor. blanking pixels = 280 = 0x118 


Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 
0x3B | | vert. Active Lines=540=0x21C_ 
Ox3C_ | Vertical Blanking Lines, lower 8 bits | ss vert. Blanking Lines = 22=0x1629 
0x3D | Vertical Active: Vertical Blanking fp 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 
(from blanking starts, lower 8 bits) 
(lower 8 bits) 
Ox40 | Vert. sync offset; Vert. sync pulse width vert. sync offset = 2 lines?° 
(upper nibble = lines, lower 4 bits of vertical vert. sync width = 5 lines 
sync offset) 
(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 


bits 7,6: upper 2 bits of Hor. sync. offset 00000000 
bits 5,4: upper 2 bits of Hor. sync pulse width 

bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


Horizontal Image Size (mm, lower 8 bits) Hor. Image size = 708 mm = 0x2C43! 
Ox43 | Vertical Image Size (mm, lower 8 bits) Vert. Image Size = 398 mm = 0x18E 


0x44 | Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 


Ox4 


2 


Ox45 | Horizontal Border (pixels) Shall be 0 


Ox46 | Vertical Border (lines) Shall be 0 


Ox47 | Flags (bit 7 = interlaced; bit 5,6 = normal 10011110 Flag = interlaced; non-stereo; digital 
display; bit 1, 2, 3,4 = sync description; bit 0 = separate; positive V sync; positive H 


do not care) sync 


| 0x39 | 
| Ox3B | 
| 
| 0x42 | 
hel 
| 0x45 | 
ial 


29 For interlaced display: Field 1 vertical blanking = Vertical Blanking Lines. Field 2 vertical blanking = Vertical Blanking Lines + 1 
Blanking Line. 


30 For interlaced display: Field 1 vertical offset = Vertical Sync Offset. Field 2 vertical offset = Vertical Sync Offset + 0.5 lines. 


31 Image size is display dependent. Ratio of Horizontal Image Size to Vertical Image Size shall be 16:9 or 4:3. 
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0x39 
Ox3A 


Ox3B 
Ux Se 
Ox3D 
Ox3E 


Ox3F 


0x40 


Ox42 
Qse43 


0x44 
Ox45 


0x46 
Ox47 
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Table 140 - Example EDID Detailed Timing Descriptor for 720x480p (59.94 Hz, 4:3) 


Byte# Value Value 

(HEX) (HEX) (binary) 
| 9x8C [Pixel Clock = 27.00 MHz 
"ox0a | 


Horizontal Active Pixels (lower 8 bits) | OxDO fo hor. Active Pixels = 720 = 0x2D0 


Pixel Clock/10,000 (LSB stored first) 


Horizontal Blanking Pixels (lower 8 bits) 


Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 
Vertical Blanking Lines, lower 8 bits 
Vertical Active: Vertical Blanking 

(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


(from blanking starts, lower 8 bits) 
(lower 8 bits) 


Vert. sync offset; Vert. sync pulse width 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 

bits 7,6: upper 2 bits of Hor. sync. offset 

bits 5,4: upper 2 bits of Hor. sync pulse width 
bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


Horizontal Image Size (mm, lower 8 bits) 


Vertical Image Size (mm, lower 8 bits) 


Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 


Horizontal Border (pixels) 


Vertical Border (lines) 

Flags (bit 7 = non-interlaced; bit 5,6 = normal 
display; bit 1, 2, 3,4 = sync description; bit O = 
do not care) 


Ose.S 
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Lr hor. blanking pixels = 138 = Ox8A 


vert. Active Lines = 480 = 0x1E0 
vert. Blanking Lines = 45 = Ox2D 


offset = 16 pixels = 0x10 


width = 62 pixels = Ox3E 
vert. sync offset = 9 lines 
vert. sync width = 6 lines 


_ ee 


Hor. Image size = 531 mm = 0x213 


Vert. Image Size = 398 mm = Ox18E (4:3 
in this case). 
| Shall be 0 
00011000 


Shall be O 


Flag = non-interlaced; non-stereo; 
digital separate; negative V sync; 
negative H sync 
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Table 141 - Example EDID Detailed Timing Descriptor for 720x480p (59.94Hz, 16:9) 


Byte# Value Value 
(HEX) (HEX) (binary) 

Pixel Clock/10,000 (LSB stored first) | Ox8C |  —————s«SYséPixel Clock = 27.00 MHz 
0x37 | Ox0A | 


Horizontal Active Pixels (lower 8 bits) | OxD0 | hor. Active Pixels = 720 = 0x2D0 
a hor. blanking pixels = 138 = Ox8A 


vert. Active Lines = 480 = 0x1E0 
vert. Blanking Lines = 45 = Ox2D 
(upper nibble = upper 4 bits of active) 


(lower nibble = upper 4 bits of blanking) fo 
Ox3E | Horizontal sync. offset (pixels) offset = 16 pixels = 0x10 
(from blanking starts, lower 8 bits) 


0x39 | Horizontal Blanking Pixels (lower 8 bits) 

Ox3A | Horizontal Active and Blanking Pixels 

(upper nibble = upper 4 bits of active) 

(lower nibble = upper 4 bits of blanking) 

0x3B 
Ox3C | Vertical Blanking Lines, lower 8 bits 

Ox3D | Vertical Active: Vertical Blanking 


© 


o) 
x | xX 
No} oo 
O| & 


Ox3F | Horizontal sync pulse width (pixels) width = 62 pixels = Ox3E 
(lower 8 bits) 


Ox40 | Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 


bits 7,6: upper 2 bits of Hor. sync. offset 00000000 
bits 5,4: upper 2 bits of Hor. sync pulse width 

bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


0x42 Oxc4 | | _Hor. Image size = 708 mm = 0x2C4_| 
ee a 
(16:9 in this case). 
0x44 | Horizontal and Vertical Image Size 2 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 
a 
fo 


vert sync. offset = 9 lines 
vert. sync width = 6 lines 


Ox43 | Vertical Image Size (mm, lower 8 bits) 


0x45 | Horizontal Border (pixels) Shall be 0 


Ox46 | Vertical Border (lines) Shall be 0 


Ox47 | Flags (bit 7 = non-interlaced; bit 5,6 = normal 00011000 | Flag =non-interlaced; non-stereo; 
display; bit 1, 2, 3,4 = sync description; bit O = digital separate; negative V sync; 


do not care) negative H sync 


188 


CTA-861-H 


Table 142 - Example EDID Detailed Timing Descriptor for 720x480i (59.94Hz, 4:3) 


Byte# Value Value 

(HEX) (HEX) (binary) 
| 9x8C [Pixel Clock = 27.00 MHz 
Cox0a | 


Horizontal Active Pixels (lower 8 bits) | OxAO [| hor. Active Pixels = 1440 = 0x5A0 


0x39 
Ox3A 


Ox3B 
Ox<3C 
Ox3D 
Ox3E 


Ox3F 


0x40 


0x42 
0x43 


Ox44 
0x45 


0x46 
0x47 


Pixel Clock/10,000 (LSB stored first) 


Horizontal Blanking Pixels (lower 8 bits) 


Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 
Vertical Blanking Lines, lower 8 bits 
Vertical Active: Vertical Blanking 

(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


(from blanking starts, lower 8 bits) 
(lower 8 bits) 


Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 

bits 7,6: upper 2 bits of Hor. sync. offset 

bits 5,4: upper 2 bits of Hor. sync pulse width 
bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


Horizontal Image Size (mm, lower 8 bits) Ox13 


Vertical Image Size (mm, lower 8 bits) 


Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 


Horizontal Border (pixels) 


Vertical Border (lines) 

Flags (bit 7 = non-interlaced; bit 5,6 = normal 
display; bit 1, 2, 3,4 = sync description; bit O = 
do not care) 


Ox14 
0325 1 
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a hor. blanking pixels = 276 = 0x114 


vert. Active Lines = 240 = OxFO 
vert. Blanking Lines = 22 = 0x16 


po offset = 38 pixels = 0x26 
a width = 124 pixels = Ox7C 


vert sync. offset = 4 lines 
vert. sync width = 3 lines 


_ ae 


Hor. Image size = 531 mm = 0x213 


Vert. Image Size = 398 mm = Ox18E 
(4:3 in this case). 
| | Shall be 0 
10011000 


Shall be O 


Flag = interlaced; non-stereo; digital 
separate; negative V sync; negative H 
sync 
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Table 143 - Example EDID Detailed Timing Descriptor for 720x480i (59.94Hz, 16:9) 


Byte# Value Value 

(HEX) (HEX) (binary) 
| ox8C [| Pixel Clock = 27.00 MHz 
Tox0a | 


Horizontal Active Pixels (lower 8 bits) | OxAO fo hor. Active Pixels = 1440 = Ox5A0 


0x39 
Ox3A 


Ox3B 
Os 3C 
Ox3D 
Ox3E 


Ox3F 


0x40 


0x42 
O43 


Ox44 
0x45 


0x46 
0x47 


Pixel Clock/10,000 (LSB stored first) 


Horizontal Blanking Pixels (lower 8 bits) 


Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 
Vertical Blanking Lines, lower 8 bits 
Vertical Active: Vertical Blanking 

(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


(from blanking starts, lower 8 bits) 
(lower 8 bits) 


Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 

bits 7,6: upper 2 bits of Hor. sync. offset 

bits 5,4: upper 2 bits of Hor. sync pulse width 
bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


Horizontal Image Size (mm, lower 8 bits) OxC4 


Vertical Image Size (mm, lower 8 bits) 


Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 


Horizontal Border (pixels) 


Vertical Border (lines) 

Flags (bit 7 = non-interlaced; bit 5,6 = normal 
display; bit 1, 2, 3,4 = sync description; bit O = 
do not care) 


Osci4 
Ox51 
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es hor. blanking pixels = 276 = 0x114 


vert. Active Lines = 240 = OxFO 
vert. Blanking Lines = 22 = 0x16 


Lo offset = 38 pixels = 0x26 
LC width = 124 pixels = Ox7C 


vert sync. offset = 4 lines 
vert. sync width = 3 lines 


_ ae 


ns Hor. Image size = 708 mm = Ox2C4 
Vert. Image Size = 398 mm = Ox18E 
(16:9 in this case). 


Shall be O 
10011000 


Shall be O 


Flag = interlaced; non-stereo; digital 
separate; negative V sync; negative H 
sync 
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Table 144 - Example EDID Detailed Timing Descriptor for 1280x720p (50 Hz, 16:9) 


Byte# Value Value 

(HEX) (HEX) (binary) 
| 0x01 | | —~Pixel Clock = 74.25 MHz 
PoxiD | 


Horizontal Active Pixels (lower 8 bits) | Ox00 | hor. Active Pixels = 1280 = 0x500 


Ox37 


0x39 
Ox3A 


Ox3B 


Ox3C 


Ox3D 


Ox3E 


Ox3F 


0x40 


Ox4 
0x43 
0x44 


Z 


0x45 
0x46 
Ox47 


Pixel Clock/10,000 (LSB stored first) 


Horizontal Blanking Pixels (lower 8 bits) 
Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


Vertical Active Lines, lower 8 bits OxDO 


Vertical Blanking Lines, lower 8 bits 
Vertical Active: Vertical Blanking 

(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


(from blanking starts, lower 8 bits) 
(lower 8 bits) 


Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 

bits 7,6: upper 2 bits of Hor. sync. offset 

bits 5,4: upper 2 bits of Hor. sync pulse width 
bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


Horizontal Image Size (mm, lower 8 bits) 


Vertical Image Size (mm, lower 8 bits) 
Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 


Horizontal Border (pixels) 
Vertical Border (lines) 


Flags (bit 7 = non-interlaced; bit 5,6 = normal 
display; bit 1, 2, 3,4 = sync description; bit 0 = 
do not care) 


© 


oO 
x 

Ol 
No 
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<BG 


i hor. blanking pixels = 700 = Ox2BC 


vert. Active Lines = 720 = Ox2D0 
vert. Blanking Lines = 30 = Ox1E 


| offset = 440 pixels = 0x1B8 
i width = 40 pixels = 0x28 


vert sync. offset = 5 lines 
vert. sync width = 5 lines 


01000000 


Hor. Image size = 708 mm = Ox2C4 


Vert. Image Size = 398 mm = Ox18E 


| Shall be 0 
00011110 


Shall be O 


Flag = non- interlaced; non-stereo; 
digital separate; positive V sync; 
positive H sync 
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Table 145 - Example EDID Detailed Timing Descriptor for 1920x1080i (50 Hz, 16:9) 


Byte# Value Value 

(HEX) (HEX) (binary) 
| 0x01 | Ys ~Pixel Clock = 74.25 MHz 
Coxip | 


Horizontal Active Pixels (lower 8 bits) | 0x80 | Hor. Active Pixels = 1920 = 0x780 


0x39 
Ox3A 


Ox3B 
Ox3C 
Ox3D 
Ox3E 


Ox3F 


0x40 


Ox4 
0x43 
Ox44 


Z 


0x45 
0x46 
0x47 


Pixel Clock/10,000 (LSB stored first) 


Horizontal Blanking Pixels (lower 8 bits) 


Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 
Vertical Blanking Lines, lower 8 bits 
Vertical Active: Vertical Blanking 

(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


(from blanking starts, lower 8 bits) 
(lower 8 bits) 


Vert sync offset; Vert sync pulse width 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 

bits 7,6: upper 2 bits of Hor. sync. offset 

bits 5,4: upper 2 bits of Hor. sync pulse width 
bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse 
width 


Horizontal Image Size (mm, lower 8 bits) OxC4 


Vertical Image Size (mm, lower 8 bits) 


Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 


Horizontal Border (pixels) 


Vertical Border (lines) 

Flags (bit 7 = interlaced; bit 5,6 = normal 
display; bit 1, 2, 3,4 = sync description; bit O 
= do not care) 
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Co hor. blanking pixels = 720 = Ox2D0 


vert. Active Lines = 540 = Ox21C 
vert. Blanking Lines = 22 = 0x16 


i offset = 528 pixels = 0x210 
tz width = 44 pixels = Ox2C 


vert sync. offset = 2 lines 
vert. sync width = 5 lines 


= ee 


Hor. Image size = 708 mm = Ox2C4 
Vert. Image Size = 398 mm = Ox18E 


Shall be O 
Shall be O 


Flag = interlaced; non-stereo; digital 
separate; positive V sync; positive H 
sync 
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Table 146 - Example EDID Detailed Timing Descriptor for 720x576p (50 Hz, 4:3) 


(HEX) (HEX) (binary) 
Ox 3:7 Ox0A 


0x38 | Horizontal Active Pixels (lower 8 bits) OxD hor. Active Pixels = 720 = Ox2D0 


© 


0x39 | Horizontal Blanking Pixels (lower 8 bits) hor. blanking pixels = 144 = 0x90 


Ox3A | Horizontal Active and Blanking Pixels Lo 


(upper nibble = upper 4 bits of active) 
Ox3B | Vertical Active Lines, lower 8 bits vert. Active Lines = 576 = 0x240 
Ox3C | Vertical Blanking Lines, lower 8 bits vert. Blanking Lines = 49 = 0x31 


Ox3D | Vertical Active: Vertical Blanking 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


(lower nibble = upper 4 bits of blanking) 


oo} ees en) @|© 
x | x1] xX x | Xx 
NO] Go] ww NO} © 
O/H) © | 


(from blanking starts, lower 8 bits) 
(lower 8 bits) 


Ox40 | Vert sync offset; Vert sync pulse width 0x55 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 


bits 7,6: upper 2 bits of Hor. sync. offset 0x00 00000000 
bits 5,4: upper 2 bits of Hor. sync pulse width 

bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


Horizontal Image Size (mm, lower 8 bits) Hor. Image size = 531 mm = 0x213 


Se 

Vertical Image Size (mm, lower 8 bits) Ox8E EE | = cell 
(4:3 in this case). 

0x44 | Horizontal and Vertical Image Size Oxz1 
(upper nibble = upper 4 bits of horiz.) i 
(lower nibble = upper 4 bits of vert.) 
| 
ers 


Width = 64 pixels = 0x40 


vert sync. offset = 5 lines 
vert. sync width = 5 lines 


S 
x 

ke 
W 


Ox4 
0x43 


2 


0x45 | Horizontal Border (pixels) x00 Shall be 0 
0x46 | Vertical Border (lines) x00 Shall be 0 


Ox47 | Flags (bit 7 = non-interlaced; bit 5,6 = normal 0x18 00011000 Flag = non-interlaced; non-stereo; 
display; bit 1, 2, 3,4 = sync description; bit 0 = digital separate; negative V sync; 


do not care) negative H sync 
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Table 147 - Example EDID Detailed Timing Descriptor for 720x576p (50 Hz, 16:9) 


Byte# Value Value 
to es | amy 
Pixel Clock/10,000 (LSB stored first) | Ox8C | |: Pixel Clock = 27.00 MHz 
| Ox0OA | 
| 0x38 | Horizontal Active Pixels (lower 8 bits) | -OxDO [| hor. Active Pixels=720=0x2D0_ 

0x39 0x90 | i hor. blanking pixels=144= 0x90 


Ox3A | Horizontal Active and Blanking Pixels 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 
0x3B 0 
Ox3C | Vertical Blanking Lines, lower 8 bits 
Ox3D | Vertical Active: Vertical Blanking 

(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


(from blanking starts, lower 8 bits) 
(lower 8 bits) 


Ox40 | Vert sync offset; Vert sync pulse width vert sync. offset = 5 lines 
(upper nibble = lines, lower 4 bits of vertical vert. sync width = 5 lines 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 

sync pulse width) 

bits 7,6: upper 2 bits of Hor. sync. offset 

bits 5,4: upper 2 bits of Hor. sync pulse width 

bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


Ox42 | Horizontal Image Size (mm, lower 8 bits) OxC4 


0x43 


e) 
x 

No 
ce) 


© 


vert. Active Lines = 576 = Ox240 
vert. Blanking Lines = 49 = 0x31 


O 
x |X 
GO] & 
po 


Vertical Image Size (mm, lower 8 bits) 


Ox44 | Horizontal and Vertical Image Size 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 


0x45 | Horizontal Border (pixels) Shall be 0 
Ox46 | Vertical Border (lines) Shall be 0 


Ox47 | Flags (bit 7 = non-interlaced; bit 5,6 = normal Flag = non-interlaced; non-stereo; digital 
display; bit 1, 2, 3,4 = sync description; bit O = separate; negative V sync; negative H 
do not care) sync 
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Table 148 - Example EDID Detailed Timing Descriptor for 720x576i (50 Hz, 4:3) 


(HEX) (HEX) (binary) 
Ox36 | Pixel Clock/10,000 (LSB stored first) Ox8C 
O53. Ox0A 


Ox38 | Horizontal Active Pixels (lower 8 bits) OxA 
0x39 | Horizontal Blanking Pixels (lower 8 bits) 


Ox3A | Horizontal Active and Blanking Pixels 0x51 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 
0x3B x20 
Ox3C | Vertical Blanking Lines, lower 8 bits x18 
Ox3D | Vertical Active: Vertical Blanking 

(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 


(from blanking starts, lower 8 bits) 
(lower 8 bits) 


Ox40 | Vert sync offset; Vert sync pulse width 0x23 
(upper nibble = lines, lower 4 bits of vertical 
sync offset) 

(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 


bits 7,6: upper 2 bits of Hor. sync. offset 0x00 00000000 
bits 5,4: upper 2 bits of Hor. sync pulse width 

bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


Horizontal Image Size (mm, lower 8 bits) Hor. Image size = 531 mm = 0x213 


Ee 
0x43 | Vertical Image Size (mm, lower 8 bits) Ox8E a = tee 
(4:3 in this case). 
0x44 | Horizontal and Vertical Image Size Ox 
(upper nibble = upper 4 bits of horiz.) pf 
(lower nibble = upper 4 bits of vert.) 
Poe 
Ld 


Pixel Clock = 27.00 MHz 


© 


hor. Active Pixels = 1440 = 0x5A0 
hor. blanking pixels = 288 = 0x120 


i) 


© 


oO oO oO 

x x x 
4 aa NO 
CO Oo CO 


Width = 126 pixels = Ox7C 


vert sync. offset = 2 lines 
vert. sync width = 3 lines 


Ox4 


Z 


0x45 | Horizontal Border (pixels) x00 Shall be 0 


0x46 | Vertical Border (lines) x00 Shall be 0 


Ox47 | Flags (bit 7 = non-interlaced; bit 5,6 = normal 0x98 10011000 | Flag = interlaced; non-stereo; digital 
display; bit 1, 2, 3,4 = sync description; bit O = separate; negative V sync; negative H 


do not care) sync 
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Table 149 - Example EDID Detailed Timing Descriptor for 720x576i (50 Hz, 16:9) 


Byte# Value Value 
owe | te ory 
Pixel Clock/10,000 (LSB stored first) | Ox8C [|__| - Pixel Clock = 27.00 MHz 
Tox0a | 
| 0x38 | Horizontal Active Pixels (lower 8bits) | OxAO_ [| | hor. Active Pixels =1440=OxSAO_ 
0x39 | | hor. blanking pixels = 288 = 0x120_ 


Ox3A | Horizontal Active and Blanking Pixels 
(lower nibble = upper 4 bits of blanking) 

0x3B | Vertical Active Lines, lower 8 bits ee ; ines = = 

Ox3C | Vertical Blanking Lines, lower 8 bits a vert. Blanking Lines = 24 = 0x18 
(upper nibble = upper 4 bits of active) 
(lower nibble = upper 4 bits of blanking) 

OxX3E | Horizontal sync. offset (pixels) offset = 24 pixels = 0x18 
(from blanking starts, lower 8 bits) 

Ox40 | Vert sync offset; Vert sync pulse width vert sync. offset = 2 lines 
(upper nibble = lines, lower 4 bits of vertical vert. sync width = 3 lines 
sync offset) 


(upper nibble = upper 4 bits of active) 
vert. Active Lines = 288 = 0x120 
Ox3D | Vertical Active: Vertical Blanking 
Ox3F | Horizontal sync pulse width (pixels) Width = 126 pixels = Ox7E 
(lower 8 bits) 
(lower nibble = lines, lower 4 bits of vertical 
sync pulse width) 


bits 7,6: upper 2 bits of Hor. sync. offset 00000000 
bits 5,4: upper 2 bits of Hor. sync pulse width 

bits 3,2: upper 2 bits of vert sync offset 

bits 1,0: upper 2 bits of vert. sync pulse width 


0x42 Oxc4 |__| Hor. Image size= 708mm -=0x2C4__ 
a 
(16:9 in this case). 
0x44 | Horizontal and Vertical Image Size ae 
(upper nibble = upper 4 bits of horiz.) 
(lower nibble = upper 4 bits of vert.) 
a 
ee 


Ox43 | Vertical Image Size (mm, lower 8 bits) 


0x45 | Horizontal Border (pixels) Shall be 0 


Ox46 | Vertical Border (lines) Shall be 0 


Ox47 | Flags (bit 7 = non-interlaced; bit 5,6 = normal 10011000 | Flag = interlaced; non-stereo; digital 
display; bit 1, 2, 3,4 = sync description; bit O = separate; negative V sync; negative H 


do not care) sync 
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ANNEX B APPLICATION TO DVI 1.0 (NORMATIVE) 


All mandatory aspects of DVI 1.0 [4] shall be implemented with the exception of those expressly 
identified as optional or informative when DVI 1.0 is used to implement CTA-861. DVI does not 
support transport of CTA InfoFrames, audio or YCgCr Pixel Data. However, CTA-861 can still be 
implemented on DVI 1.0 (with reduced functionality) as explained at the beginning of Section 6. 


The EDID content shall comply with EDID data structure Version 1, Revision 3 [9]. 


All sections in Annex B are normative when DVI 1.0 is used to implement CTA-861 except as 
otherwise noted. 


B.1 Connector and Cable 
The connector used shall be DVI-Digital, Single Link [4]. 


The cable, if supplied with the product, shall be compliant with the DVI specification at 
maximum pixel clock frequency compatible with the product. 


B.2 Digital Content Protection 


High-bandwidth Digital Content Protection (HDCP) version 1.1 [3] or later is available to protect 
the video data carried on a DVI link. 
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ANNEX C APPLICATION TO OPEN LDI (NORMATIVE) 


All mandatory aspects of OpenLDI 0.95 [8] shall be implemented with the exception of those 
expressly identified as optional or informative in that standard when OpenLDI 0.95 is used to 
implement CTA-861. It should be noted that at the time of this writing, a version of OpenLDI 
that supports transport of CTA InfoFrames was not available. However, CTA-861 can still be 
implemented on OpenLDI 0.95 (with reduced functionality) as explained in Section 6. 


All sections in this Annex are normative when OpenLDI 0.95 is used to implement CTA-861 
except as otherwise noted. 


C.1 Open LDI Data and Control Signals 
OpenLDI has two options for display synchronization: 
a) DC Balance Mode 

b) Non DC Balance Mode 


In DC Balance mode synchronization is accomplished by transmitting control signals during the 
Display blanking intervals as shown in Figure 8. 


Figure 8 - OpenLDI Synchronization 


In the single or dual LVDS bus mode (24 or 48 bit Total), the control signals are transmitted over 
7 transition words on specific output signals during the blanking period as indicated in Table 
150. 


Table 150 - OpenLDI Control Signals 


Control Signal Signal Level Output Signal Data Pattern 


CLK1 and CLK2 1111000 or 1110000 
| 1111100 or 1100000 or 1100000 


198 


CTA-861-H 


C.2 Non DC Balanced Mode 


Control signals are transmitted as part the LVDS serialized data stream. The controls signals are 
then de-serialized and regenerated at the receiver outputs to the HDTV. 


C.3. OpenLDI Cabling Information 


An OpenLDI cable assembly shall consist of a cable meeting the requirements of this section 
with an OpenLDI plug on each end or an OpenLDI plug on one end and the other end 
permanently affixed to the display device. Acceptable cables for OpenLDI may use either 
shielded or unshielded twisted pairs. It is up to the manufacturer of the OpenLDI equipment to 
use the grade and type of cable required to meet applicable regulatory requirements. 
Adherence to CTA-861 does not guarantee regulatory compliance. 


When the OpenLDI is an interface internal to an assembly and not accessible externally, the 
OpenLDI cable may be replaced with any cable or connection means appropriate to the 
requirements of the assembly. 


C.3.1 Cable Length 


The maximum cable length shall be 10m. 


C.3.2 Number of Signal Conductors 


The OpenLDI cable shall comprise 11 twisted pairs and 10 individual conductors. 


C.3.3 Wire Gauge 
Each conductor in an OpenLDI cable shall be no less than 28AWG. 


C.3.4 Conductor Resistance 


The resistance of a single conductor of an OpenLDI cable shall not exceed 402 when the 
conductor is of the maximum length specified in CTA-861. 


C.3.5 Insulation 


Each conductor in the cable shall be separately insulated. The minimum insulation resistance 
Shall be 1GQ. 


C.3.6 Shield Requirement 


The OpenLDI cable shall be encompassed by a single shield, surrounding all conductors in the 
cable. The shield shall provide a minimum of 90% coverage. 


For shielded twisted pair cable, each twisted pair shall be shielded individually. Each shield shall 
provide a minimum of 90% coverage. 
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C.3.7 Single Twisted Pair Transmission Skew 


The differential time of transmission (single pair transmission skew) of a pulse through a single 
differential pair in an OpenLDI cable shall not exceed 300ps. 


C.3.8 Multiple Twisted Pair Transmission Skew 


The differential time of transmission (pair to pair transmission skew) of a pulse through any two 
differential pairs in an OpenLDI cable shall not exceed 1 bit time. 


C.3.9 USB Cable Requirements 


The conductors used for transmission of USB signals on the OpenLDI cable shall meet the 
requirements stated in the Universal Serial Bus Specification, Version 1.0, January 15, 1996. 


C.3.10 DDC Cable Requirements 


The conductors used for transmission of DDC signals on the OpenLDI cable shall meet the 
requirements stated in the VESA Display Data Channel Command Interface (DDC/CI) Standard, 
Version 1, August 14, 1998 [10]. 


More information on the connector is available in Section 7.2 of the OpenLDI specification [8]. 
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ANNEX D APPLICATION TO HDMI (INFORMATIVE) 


D.1 InfoPackets 


HDMI carries each InfoFrame in its own HDMI packet. The HDMI packet type for an InfoFrame 

packet is equal to Ox80+InfoFrame Type, therefore, only InfoFrames with Types less than 0x80 

may be transmitted. Including Type, Version, and Length fields, InfoFrames of at most 30 bytes 
are supported. A checksum is present in each InfoFrame. 


Refer to the HDMI Specification for more detail on the packetization of InfoFrames. 


D.2 EDID 


A Sink using an HDMI input shall contain an EDID consisting of a single E-EDID Version 1, 
Revision 3 block and at least one CTA Extension version 3. 


A Sink that supports either type of YCgCe Pixel Data (4:2:2 or 4:4:4) shall support both types and 
therefore shall set both bits 4 and 5 of byte 3 of all CTA EDID Extensions within the EDID. A Sink 
that does not support YCgCr Pixel Data shall have both bits 4 and 5 clear. See D.6 for an 
example. 


If the Sink supports any type of digital audio on this interface, then it shall also support Basic 
Audio and shall indicate this by setting the Basic Audio bit (bit 6). 


Bit 7 of byte 3 shall be set if the Sink underscans IT Video Formats by default. 


D.3 Audio 


HDMI [110] is capable of supporting a variety of audio formats, including uncompressed digital 
audio (L-PCM), in an IEC 60958-3 [12] compliant stream at up to 8 channels, up to 192 kHz and 
up to 24 bits/sample, and compressed digital audio, in an IEC 61937-2 [129] compliant stream, 
up to 192 kHz. 


HDMI [110] relies on the defined audio discovery mechanisms present in the CTA EDID 
Extension Version 3. 


The Audio InfoFrame, the IEC 60958-3 [12] “Channel Status” bits, and the IEC 61937-2 [129] 
“Burst Info” bits are used to describe the transmitted audio stream. The Audio InfoFrame CT 
(coding type), SS (bits/sample) and SF (sample frequency) fields are required to be O (“Refer to 
Stream Header”) to avoid redundancy with the same data already contained within the IEC 
60958-3 [12] stream data. 


D.4 HDCP 


High-bandwidth Digital Content Protection (HDCP) version 1.1 [3] or later is available to protect 
the audio and video data carried on an HDMI link. 


201 


CTA-861-H 


D.5 Additional Information 
HDMI information is available from HDMI Licensing (see Section 2.1.2). 


HDCP information is available from Digital-CP, LLC (see Section 2.1.1). 


D.6 Example EDID Using Elements of CTA Block Tag Extension (Applicable to 
HDMI) 


Table 156 contains an example implementation of EDID utilizing elements of the CTA Block Tag 
Extension that were not addressed in Annex A. These elements are Short Video Descriptors, 
Audio Descriptors, Speaker Allocation Data Block, and a Vendor-Specific Data Block. This 
example is applicable to HDMI implementations. Elements of the Example EDID are addressed 
individually, in the following subsections. 


D.6.1 First Monitor Descriptor (Monitor Name) and Second Monitor Descriptor 
(Monitor Range Limits) 


Although Annex A requires that two of the four 18-byte detailed timing descriptors be a 
Monitor Name Descriptor and a Monitor Descriptor, it is possible that implementations 
designed for Personal Computers (e.g., multimedia applications), may contain a different set of 
data. For that reason, Sources adhering to CTA-861 should be designed without dependency 
upon specific data within these blocks that prevent collection and interpretation of subsequent 
data blocks. 


D.6.2 Extension Flag and Checksum 


The Extension Flag and Checksum are defined the same as in A.2.11. 


D.6.3 CTA Extension Header (Block 1) 


The CTA Extension Header is a four-data bytes located in address range 0x80 through 0x83. The 
first byte is the tag used to identify the extension. The number assigned by VESA to this tag is 
0x02. Following the CTA Extension Tag is the Revision Number location. In this example, the 
Revision Number is set to 0x03. Please note that all Revision numbers are backward 
compatible. Sources should not have a dependency upon Revision Numbers. 


Table 151 contains data based upon the tables presented in this Annex. In this example, the 
CTA Extension Tag is located at address 0x80 followed by Revision Number, Byte Number 
Offset, and Reserved (i.e., 0x00). The data is set as prescribed by CTA-861. 
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Table 151 - CTA Extension Header (Block 1) 


Address Example Data Name of Block Description 
Hex Hex Dec 


CTA Extension Header Block One 


Ox81 0x03 3 Revision Number Start of CTA Block Tag 
Extension 


a A 


(4:2:2) 


D.6.4 CTA Data Block Collection 


The CTA Data Block Collection is within the CTA Extension Block and declares video and audio 
capabilities, soeaker configuration, and Vendor-Specific Data Blocks that require an identifier 
code and carry additional and optional data. As noted in Section 7.3.3, the Data Block ordering 
sequence is not constrained and various combinations are possible; and therefore, the 
examples provided herein are based upon one possible combination. 


D.6.5 Video Data Block 


The purpose of this data block is for listing Short Video Descriptors (SVDs). Short Video 
Descriptors are used to declare Video Formats with one byte as contrasted with 18 bytes for 
Detailed Timing Descriptors, which is useful in economizing memory space. SVDs may be used 
as SVRs in the VFPDB to indicate Video Format preference (Section 7.5.12). Although the order 
of SVDs in VDBs is not important, legacy Sources that do not parse the VFPDB may consider the 
first one most-preferred. 


As defined in Table 59 (General Tag Format), the first byte is used to signify a Video Tag Code 
and Payload Length. Bits 5 to 7 designate the Tag Code and payload length is defined by bits 0 
to 4. 


The payload byte structure is defined in Section 7.5.1. 


In the example, as shown in Table 152, bits 5 through 7 located in address 0x84 are set to Tag 
Code 2 (0x04) designating a Video Data Block; and bits 0 to 4 is set to 0x7 indicating seven bytes 
of data payload. Addresses 0x85 through Ox8B contain one discrete Short Video Descriptor 
code per byte. 
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Table 152 - Video Data Block 


Address Example Data Name of Data Block Description 
Hex Hex Dec 


0x84 0x47 Video Data Block Start of data block collection. | Ox47 = Video Data Block (code = 2) 
Includes Tag Code and length | and seven bytes of data payload 
of following data block 
payload 


| | 1st Short Video Descriptor 1920x1080i @ 59.94/60 Hz 16:9 
Native Mode 


nate pe 
joxg7 | oxo, | 3 | | 3 Short Video Descriptor | 720x480p 59.94/60Hz 16:9 
poxgs | xed fA | Short Video Descriptor | 1280x720p 59.94/60H216:9 | 
poxgo foxes, f6@ | | Short Video Descriptor | 720(1440)x480i 59.94/60 Hz 4:3 | 
oxea | oxo7_ | 7 | | Short Video Descriptor | 720(1440)x480i 59.94/60 Hz 16:9 _| 
poxsa ff owon ft Short Video Descriptor | 640x480p 59.94/60H24:3 


D.6.6 Audio Data Block 


The Audio Data Block is used to declare format, frequency, and bit-rate. The structure of this 
table is defined in Section 7.5.2 with subsequent tables addressing the General Tag Format, 
Short Audio Descriptors, and Audio Format Codes. Multiple Short Audio Descriptors may be 
used in this data block. 


The first byte in this data block is the General Format Tag and is the same structure as the Video 
Data Block as defined in Table 59, General Tag Format. The Tag Code occupies bits 5 through 7; 
and Payload Length is placed in bits 0 through 4. Audio Format Codes are listed in Table 37. 
Three bytes of data are used for each Short Audio Descriptor. 


Short Audio Descriptors are defined in Section 7.5.2. Each Descriptor consists of three data 
bytes. 


In Table 153, as with the Video Data Block, the first byte (Ox8C) is used to indicate data block 
type and payload length in bytes. Audio Tag Code 1 (0x02) is placed in bits 3 and 7; and bits 0 to 
4 contain 0x3 for a payload of three bytes. The Short Audio Descriptor begins at address Ox8D 
and ends with Ox8F. In the first byte of the descriptor, bit 7 is reserved and set to ‘zero’. Bits 3 
through 6 contain the Audio Format code as defined in Table 66; in this example Code 1 for L- 
PCM is indicated with bit 6...3 set to ‘0001’. Bits O through 2 designate the maximum number of 
audio channels as two channels (0x1). The second descriptor byte uses seven bits to declare 
frequency characteristics. Frequencies of 32 kHz, 44.1 kHz, and 48 kHz are indicated by the 
value 0x07 in address Ox8E as defined in Table 66. In address Ox8F, the value 0x07 is used to 
declare audio sample sizes of 16, 20, and 24 bit as defined in Table 66. This example does not 
illustrate Short Audio Descriptors for Compressed Audio formats. 
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Table 153 - Audio Data Block 


Hex Hex Dec 
three bytes of data payload. 


poxsd_ | x09 | 9 | Audio Format | Code 1 = L-PCM (IEC 60985) 
poxse | oxo7_ | 7 | Frequency | 0x07 = 32 kHz, 44.1 kHz, 48 kHz 
poxse ft oxo7_ 7 Bits / Sample 0x07 = 16 bit, 20 bit, 24 bit 


D.6.7 Speaker Allocation Data Block 


The Speaker Allocation Data Block is used to declare number of speakers and configuration. As 
with preceding data blocks, a Tag Code and payload length are designated in the first byte. The 
data block payload begins with the second byte and is used to indicate speaker count and 
configuration (see Table 76). The last payload byte is set to zero. 


In Table 154, address 0x90 contains a value 0x83, which designates the beginning of the 
Speaker Allocation Data Block and data payload. In this example, the Speaker Allocation Data 
Block is indicated by Code 4 per Table 76.The data payload is set to three bytes. At address 0x91 
FL/FR (2 Channel Stereo) is chosen by setting the bits to 0x01. The two remaining addresses 
have the bits set to zero as required by Section 7.5.3. 


Table 154 - Speaker Allocation Data Block 


Hex Hex Dec 
0x90 0x83 131 Speaker Allocation Data | Start of Speaker Allocation 0x83 =Speaker Allocation Data 
Block Block (code = 4) and three 
bytes of data payload. 


Ox91 Ox01 Speaker Designation Ox01 = FL / FR (2 Channel 
BIcie: ) 


(0x92 [oxoo [Oo | Speaker Designation 
pox93 ff oxoo Po Reserved | Awayszero 


D.6.8 Vendor-Specific Data Block 


The Vendor-Specific Data Block was originally intended as an option to place data not specified 
by CTA-861; data that a manufacturer may care to use. However, the HDMI specification makes 
requirements that are addressed below. Users are advised to treat this data block with care. 


The first address requires a Tag Code and data payload length in the first byte. The next three 
addresses house a 24-bit IEEE Registration Identifier (three bytes); and a Vendor-Specific 
Payload in the remaining bytes. In the case of HDMI compliant devices the IEEE Registration is 
used as an ‘HDMI Identifier.’ After the HDMI Identifier two bytes are used to identify the port 
configuration. Users are advised to refer to the HDMI specification for details. For the purposes 
of this example the HDMI Identifier and Physical Source Address are presented. 
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As shown in Table 155, the first address, 0x94, the Tag Code is listed as ‘3’ and the payload 
length is set to ‘5S’ bytes. The second, third and fourth bytes, addresses 0x95, 0x96 and 0x97, 
contain the HDMI LLC’s 24-bit IEEE registration Organizationally Unique Identifier (OUI) 
Ox000CO3, which is coded least significant byte first. The Physical Source Address is found in 
address 0x98 and 0x99 and according to the HDMI specification, the two bytes are used as 
Identity Port Configuration with 0x1000 indicating a single port Sink. 


Table 155 - Vendor-Specific Data Block 


ter [her pe [eee Pee Oe 
Hex Hex Dec 
0x94 Ox65 101 Vendor-Specific Data Block Start of Vendor-Specific 0x65 = Vendor-Specific Data 
Data Block Block (code = 3) and five bytes 
of data payload. 


24-bit IEEE Registration HDMI Identifier = Ox000C03 
(The big-endian HDMI-LLC's 24- 


0x97 0x00 bit OUI Registration Identifier 
Ox000C03 is placed into the 
EDID in little-endian order.) 


Components of Source Sink identifies location of 


0x99 0x00 Physical Address Source in signal path relative to 
root display as ABCD. Example 
shows input ‘1’ of root display 
(A=1, B=0, C=0, D=0 or 
0x1000). 
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D.6.9 Complete CTA-861 Example with Block Tag Extension 


Table 156 contains an example implementation of E-EDID utilizing elements of the CTA Block 
Tag Extension that were not addressed in Annex A. These elements are Short Video Descriptors, 
Audio Descriptors, Speaker Allocation Data Block, and a Vendor-Specific Data Block. This 
example is applicable to HDMI implementations. 


Table 156 - CTA-861 EDID Example with Block Tag Extension 


Address Example Data Name of Block Description 
Hex Hex Dec 


}0x00 =| ox0o0 =f Oo | Block Zero Header Fixed Value 
0x07 | oxo =| 0 


Vendor / Product ID Manufacturer Name CTA 


}Ox0OA «| Ox00 =O Product Code Used to differentiate between 
Ox0B 0x00 jane oni different models from the same 

manufacturer. 

}oxoc =| ox0o0 =} OC Serial Number Optional. 

/OxOD | 0x00 {oO | The serial number can also be 

}Ox0E | 0x00 {Oo | stored in a separate descriptor 

OxoF | Oxoo | OO aleck 

a ie Week of Manufacture Optional. 
If this field is unused, the value 
should be set to 0. 

Revision Revision # as 


3 
0x14 0x80 128 Basic Display Parameters / Video Input Definition Digital, VESA DFP1X : not 
Features compatible 


epee Max. Horizontal Image Size | Optional. 


incm The system should not make 
any assumption regarding 


display size 


cm See above. 
100 = value (2.2 x 100)-100 = 120 


Feature Support Ox0A denotes: 
RGB color Display type, 
preferred timing: first detailed 


timing block. GTF timing: not 


supported. Standby mode: not 
supported, suspend mode: not 
supported, active off: not 
supported 
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Table 156 - CTA-861 EDID Example with Block Tag Extension (continued) 


Hex Hex Dec 

Color Characteristics |Red/GreenlowBits | Sd 
| Blue/WhiteLlowBits | 
|Ox1B_| OxAO_| 160 
Established Timings 
| ox24 | Ox00 | O 


Ox25 0x00 Manufacturer's Reserved None 
hace hall al — 
ID #1-8 


Standard Timing ID #5 PC Application 


Standard Timing ID #6 PC Application 
PC Application 
| 0x33 | 0x01 kT 


Standard Timing ID #8 PC Application 
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Table 156 - CTA-861 EDID Example with Block Tag Extension (continued) 


Address Example Data Name of Block Description 
Hex Hex Dec 
First Detailed Timing maith re 


Descriptor 


(Preferred) 
|HActive:HBlanking =| 
|VActive:VBlanking | Cd 
| Ox3F | Ox2c_ | 44 
a ae [wsoreer vspucewamn [| 
VS Offset: VS Pulse Width 
0x44 | x31 | 49 H&V Image Size 
(Ox45 | ooo, fo H Border 


|Ox46 | oxoo | OT 


Second Detailed Timing 
Descriptor 


V Border 


Flags Interlaced, normal display no 
stereo, digital separate, Vsync 


polarity is positive, Hsync 
polarity is positive 


Pixel Clock 27 MHz 


(Next Preferred) H Active 
H Blanking 
|HActive:HBlanking =| CCCCCid 
|VActive:VBlanking | —C—CiCis 
Ser | [wsomecveruewsn | 
VS Offset: VS Pulse Width 
H&V Image Size 
0x57 | oxo, fo H Border 
|oxs8 | oxo, fo V Border 


Flags non-interlaced, normal display 


no stereo, digital separate, V. 
and H. sync polarity is negative 
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Table 156 - CTA-861 EDID Example with Block Tag Extension (continued) 


Address Example Data Name of Block Description 
Hex Hex Dec 


|OxSB | 0x00 | O__| Mandatory 


|oxsc_ | 0x00 | 0 |_ (Monitor Name) |Flag(Reserved) | 
|OxsE | Ox00, [0 Fag 
PM 
|ox6o | Oxs9 | 89 a ee 
aa © ee 
a a 
| 0x63 | 0x4 68 a 
| 0x64 | xsd 84 fee 
foxes | Ox56 | 86 a 
aa 
EE 
a 
es 
ae (a 
rr 
}Ox6c | 0x00 |O | Second Monitor Descriptor 
| ox6E | 0x00 | 0 (range limits, binarycoded) | Flag(Reserved) | 
coded, mandatory block 

|ox70 | x00 [Oo iy 
| 0x74 | Ox2E_ | 46 

rate in MHz/10 
a ee Tag for secondary timing No secondary timing formula 

formula, GTF (Ox00=not supported 

used) 
ee 
I 
| 
ed 
ed 
ed 
Fixed | 


210 


CTA-861-H 


Table 156 - CTA-861 EDID Example with Block Tag Extension (continued) 


Hex Hex Dec 
blocks to follow 


Ox7F OxCO 192 Checksum Checksum Block 0 sum = 
OxFF&(0x100-(0x1B40&0xFF) = 
OxCO 


CTA Extension Header Block One 
Ox81 0x03 3 Ox03 (see Annex A.2.13) Revision Number (Start of VESA 
CTA Block Tag Extension) 


0x04, no data in Reserved Byte Offset 


0x83 Ox71 113 Global Declarations Content depends on 
implementation DTV, YCgCp 
(4:4:4), YCgCe (4:2:2) 
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Table 156 - CTA-861 EDID Example with Block Tag Extension (continued) 


ami — CTA Data Block Collection Start of data block 
Video Data Block 


collection. Includes Tag 0x47 = Video Data Block (code 
oll babel 


Code and length of = 2) and seven bytes of data 
following data block payload 
payload 


1st Short Video Descriptor 1920x1080i @ 59.94/60 Hz 
Son Mieo deer | teoneweMode 
oxs6 | oxo2_ | 4 


5th Short Video Descriptor 720 (1440)x480i 59.94/60 Hz 
4:3 

6t Short Video Descriptor 720 (1440)x480i 59.94/60 Hz 
16:9 


7* Short Video Descriptor 640x480p 59.94/60 Hz 4:3 


Start of Audio Data Block 0x23 = Audio Data Block (code 


a a 


“— 


= 1) and three bytes of data 


payload. 
inal ical ll 
[12]) 
|ox8F | oxo7_ | 7 
0x90 0x83 Speaker Allocation Data Block | Start of Soeaker Allocation 0x83 =Speaker Allocation Data 
text Block (code = 4) and three 
pytes of data payload. 
Stereo. FITS 
ial (oak eave | Gees 
|ox93 | x00 | O Always zero 
0x94 0x65 101 Vendor-Specific Data Block Start of Vendor-Specific 0x65 = Vendor-Specific Data 
‘ll al gall Data Block Block (code = 3) and five bytes 
of data payload. 
24-bit IEEE Registration HDMI Identifier = Ox000C03 
(The big-endian HDMI-LLC's 24- 
0x97 0x00 bit OUI Registration Identifier 
—_ Ox000C03 is placed into the 
per ee EDID in little-endian order.) 
Components of Source Sink identifies location of 


0x99 0x00 Physical Address Source in signal path relative to 
root display as ABCD. Example 
shows input ‘1’ of root display 
(A=1, B=0, C=0, D=0 or 0x1000). 
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Table 156 - CTA-861 EDID Example with Block Tag Extension (continued) 


Hex Hex Dec 
Third Detailed Timing 
Descriptor ee aS (ed 
poxsc | oxoo, [0 
H Active: H Blanking po 
V Active 
V Blanking 
V Active: V Blanking po 
H Sync Offset 
| OxA3_ | 0x28 | 40 H Sync Pulse Width 

OxA4 0x55 85 VS Offset: VS Pulse Width Sync Offset = 5 lines, Sync 
asa hall nl 

OxA5 0x00 HS Offset: HS Pulse Width: i 

VS Offset: VS Pulse Width 

H Image Size 
V Image Size 
| OxA8— | 0x31 49 H&V Image Size 
| Oxa9 | oxo, [0 H Border 


|OxAA | ox0o, | OT 


V Border 


Flags Non-interlaced, normal display 


no stereo, digital separate, H 
and V sync polarity is positive 


Fourth Detailed Timing Pixel Clock 
Descriptor ee ce | 
H Active 
H Blanking 
H Active: H Blanking 2 es 
V Active 
V Blanking 
| oxB3_ | oxo, [0 V Active: V Blanking as 
H Sync Offset 
H Sync Pulse Width 
OxB6 0x43 67 VS Offset: VS Pulse Width Sync Offset = 4 lines, Sync 
Gaal fal all 
OxB7 0x00 HS Offset: HS Pulse Width: a 
VS Offset: VS Pulse Width 
H Image Size 
V Image Size 
H&V Image Size 
|oxBB_ | oxo [0 H Border 


|OxBC | 0x00 | 0 


V Border 


Flags interlaced, normal display no 


stereo, digital separate, V. and 
H. sync polarity is negative, 
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Table 156 - CTA-861 EDID Example with Block Tag Extension (continued) 


Hex Hex Dec 
Fifth Detailed Timing 
Descriptor ea ca 
H Active: H Blanking 
V Active 
V Blanking 
V Active: V Blanking 
H Sync Offset 
H Sync Pulse Width 

=6 
OxC9 0x00 HS Offset: HS Pulse Width: i , 
VS Offset: VS Pulse Width 

H Image Size 
V Image Size 
Poxcc | 0x31 | 49 H&V Image Size 
}OxcD | Ox00 | O H Border 


|OxcE | x00 | OT 


V Border 


Flags Non-interlaced, normal display 


no stereo, digital separate, V. 
and H. sync polarity is negative, 


Sixth Detailed Timing Pixel Clock 
Descriptor Ree | 
H Active 
H Blanking 
H Active: H Blanking 2 es 
V Active 
V Blanking 
| OxD7_ | oxoo =| O V Active: V Blanking as 
H Sync Offset 
H Sync Pulse Width 
OxDA 0x43 67 VS Offset: VS Pulse Width Sync Offset = 4 lines, Sync 
Seas ic a 
OxDB 0x00 HS Offset: HS Pulse Width: ys 
VS Offset: VS Pulse Width 
H Image Size 
V Image Size 
| OxDE | 0x31. 49 H&V Image Size 
|OxDF | oxo {0 H Border 


|OxEO | x00 | OT 


V Border 


Flags interlaced, normal display no 


stereo, digital separate, V. and 
H. sync polarity is negative 
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Table 156 - CTA-861 EDID Example with Block Tag Extension (continued) 


roe? [000 [0 Padding Bytes 
|Oxe3 | oxoo, | 0 
|Oxe4 | oxoo | 0 
|Oxe5 | oxoo, | OT 
|Oxe6 | oxoo, | OT 
|OxE7 | oxoo, | OT 
|Oxes | ox00, | OT 
|OxEo | oxoo | OT 
|OxEA | oxoo, | 0 
/OxEB | x00, | OT 
|OxeEC | ox0o | 0 
|OxED | oxoo | 0 
|OxeE | ox00, | OT 
|OxEF | oxoo, | 0 
|OxFO | oxoo | OT 
|OxF1 | oxoo, | 0 
|OxF2 | ox0o | OT 
|OxF3 | x00, | OT 
|OxF4 | ox0o, | OT 
|OxFS | oxoo, | 0 
|OxF6 | ox0o, | OT 
|OxF7 | ox0o, | OT 
|OxF8 | oxoo, | 0 
|OxF9 | ox0o, | OT 
|OxFA | ox0o, | OT 
|OxFB | ox0o, | OT 
|OxFC | oxoo, | OT 


|OxFD | oxoo, | 0 
|OxFeE | oxoo, | OT 


eee ee 


Block 1 sum = 
OXxFF&(0x100-(0x1686&0xFF) = 
Ox7A 
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ANNEX E [RESERVED FOR FUTURE USE] 
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ANNEX F GUIDANCE FOR SOURCE & SINKS (INFORMATIVE) 


F.1 Overview 


This Annex is intended to complement Section 7.2.2 “Source Requirements and 
Recommendations” and provide background and more detail to the recommendations therein. 


The essence of that guidance is thus: video Sources should provide a Source Pass-through mode 
for content in its Native Video Format (avoiding scaling, frame rate converting interlacing, and 
deinterlacing). By using Source Pass-through Mode, it is more likely that only one (if any) format 
conversion occurs. When more than one format conversion occurs, generally more artifacts 
become evident in the content being presented. However, applying Source Pass-through Mode 
is dependent on the use case in which content is being viewed. 


Consistent application of the recommendations herein will help create to an ecosystem of CTA- 
861 conformant devices with the best possible out of box experience for consumers, regardless 
of brand name purchased. 


F.2 Background 


The video processing chain from content production to presentation is envisioned as a set of 
black boxes that are integral to video distribution as shown in Figure 9. It does not show the 
audio processing chain. 


Compressed Transmission 
Content Hedd-end/;, «hates een esses ea ae eae ees Sink / 


generation/ transmission Rendering 
Compression system Device 


Source Device / 
Decompression Decompressed 
contenv/ limited 


Physical Media Distribution meta-data 


Figure 9 - Video Processing Chain 


Examples of Sources include CE devices (e.g., STBs, DVD players), IT devices (e.g., PCs), and 
convergent devices (e.g., PC/STB). Examples of Sinks are DTVs, PC Monitors and possible 
convergent display devices (repeaters and splitters are not dealt with in this Annex). 


The main interface of concern treated here is, the “Uncompressed data/Limited meta-data” link 
between the Source and the Sink. 


Because the Sink (in this case assumed to be a rendering device) is the last component in the 
device chain, it is incapable of enforcing any control over preceding devices with respect to 
video processing. Furthermore as there is no closed loop communication between Sinks and 
Sources, these devices cannot negotiate as to where a certain function should or will be carried 
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out (i.e., — scaling). To assure best performance of a complete system, a set of guidelines for 
default behavior, especially for Sources, is needed. Two common usage scenarios exist that 
dictate different default behaviors. 


1) Use cases where the source material’s Video Format is stable and unchanging for an 
extended period of time, (i.e., — playback of a movie). 


2) Use cases where the source material’s Video Format is often changing (i.e., — channel 
surfing). 


F.3 Guidance for Sources 


F.3.1 Stable Video Format 


Recommended default setting for use cases where a Video Format is expected to be stable: The 
Source should transmit video in its Native Video Format directly to the Sink without interlacing, 
deinterlacing, frame rate converting or scaling (see Source Pass-through Mode, Section 7.2.2), 
provided that support for that format is indicated in the Sink’s EDID. Examples of this are 
illustrated in Figure 10 (b) and Figure 11 (d) & (f). Figure 10 (b) and Figure 11 (c) & (e) are 
examples of not passing through the Native Video Format, resulting in multiple conversions. 


a) Use cases that are covered by this recommendation include: 

i. Playback from an optical disc player.°? 

ii. Playback from a Digital Video Camera (usually recorded at a single 
resolution). 

iii. Presentation of an IT device. 
iv. Playback of premium content from a STB. 
b) The reason this setting is recommended as default is that: 

i. Sink (display) devices are often built with high quality signal processing 
(scaling, etc.) capabilities as a key differentiating feature. Although there 
are Sources that deliver excellent scaling ability, most Sources are 
optimized to deliver their key function (i.e., optical playback, interface to 
the managed network). 

ii. Display devices are optimized to process signaling based on their own 
characteristics and properties. These properties may shift over the life of 
a display, temperature, and on-time, among other possibilities. Only the 
display itself is capable of monitoring and compensating for these shifts 
in parameters, nor is there a way for a Sink to completely communicate 
such parameters to a Source. 


32 In spite of the fact that previews, or other features may be in different formats than the full length feature, users will tolerate 
video muting when switching modes (i.e., — switching from menu to main feature). Viewing of full length features will be 
optimized. 
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c) The Source Pass-through Mode does not exclude the possibility of graphics 
overlay onto the original content (e.g., User Interface, Closed Captions, etc.). 

d) For IT Sources that place the video content inside a fixed or resizable window, 
these rules do not necessarily apply. 


F.3.2 Changing Video Format 


Recommended default setting for use cases where a Video Format is expected to change often: 
The Source should, by default, generate video in the Preferred Timing Format of the Sink as 
indicated in the VFPDB (Section 7.5.12). Examples of this are shown in Figure 10 (a) and Figure 
11 (c) & (e). 


a) Use cases that are covered by this recommendation include: 
i. Playback from a STB where the user is channel surfing. 
ii. | Playback of broadcasts where the native resolution of the transmission stream is 
changing often (e.g., — program splicing, dynamic ad insertion). 


MPEG source 


format (as decoded) Interface Sink 


1080i 1080i (pref..——® | 16:9 Display 


(a) (b) 


720p 
480i 


480p 


Figure 10 - Example of Options for Format Conversion 


In the example shown in Figure 10, the Sink indicates by its EDID data that it has a preferred 
format of 1080i, and that it can accept 1080i, 720p, 480i, or 480p. In the cases labeled (a), the 
conversion from the source material (which may be received and decoded as 1080i, 720p, 480i 
or 480p) to 1080i is happening in the Source. In the other case, labeled (b), the Source does no 
format conversion and delivers the as-decoded format across the interface. Conversion to 1080i 
is happening in the Sink. If the Sink is a multi-scan capable display and indicates the other 
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formats are supported natively also, the best image presentation probably results if the 
conversion takes place in the Sink. 


MPEG source 


format (as decoded) Interiace Sink 


1080i EE 1080i 


(Cc) | (d) 


720p 720p (pref.) =] 


16:9 1024x576 
LCD Display 


(e) 


(f) 


480i 480i 


480p 


Figure 11 - Multiple Conversions Example 


In the example in Figure 11 the Sink can once again support 1080i, 720p, 480i, or 480p. In this 
case, the display is a 1024 by 576 LCD panel so none of these formats is native, and 720p is 
indicated as being “preferred.” The illustration shows conversions either taking place in the 
Source, in the Display, or in both. Any conversion performed in the Source is to 720p because 
720p is indicated as the preferred format. This is a situation where at least one conversion 
takes place. In general, format conversions introduce errors and display artifacts. In the 
optimum system, at most one format conversion should be done between the MPEG-2 decoder 
and visual presentation. In Figure 11, MPEG-2 video in 1080i format is decoded, and can be 
converted (c) into the Sink’s preferred 720p format. In this case, the Display re-converts 720p 
into its native 1024x576 LCD format. Alternatively, the 1080i video can be delivered un- 
converted across the interface (d) where the Display performs one conversion to its Native 
Video Format. The cases marked (e) are similar, in that two conversions result if the Source re- 
formats into 720p before delivering the data across the interface. In the remaining cases the 
video is delivered in the same format as it was decoded, resulting in only one conversion. These 
cases illustrate that the best visual presentation may result when the Source transports (passes 
through) the video to the Sink in the same basic format as the decoded MPEG2 stream 
(assuming the ultimate source is MPEG2). 


220 


CTA-861-H 


F.3.3 Optional User Controlled Setting 


Naturally, user accessible features to override default settings in Sources are allowed. These 
types of user controls enable flexibility beyond the recommendations above. Such controls 
could enable better picture quality in the case of, for instance, use of an A/V receiver containing 
a high quality image processor. In such a case, it might be better to utilize the image processor 
of the A/V receiver, rather than allowing the display device to handle the video processing (the 
default recommendation). 


F.3.4 Non-Default Scenarios 


When a Source is incapable of supporting the recommendations in Sections F.3.1 & F.3.2 above, 
then it should still follow the general recommendations for the appropriate use case, (i.ée., 
following or not following the source material Video Format at its output). In such 
circumstances (i.e., Native Video Format of video source, or preferred timing mode not 
supported) the Source should generate an appropriate Video Format at its output, following the 
rules of precedence described in CTA-861 (based on the ordering of Video Formats in EDID). 


a) The Source should first attempt to convert the content to the Video Format described at the 
lowest address in the EDID. 


b) If the Source cannot convert to the first format listed in the EDID, then it should transform 
the content to the Video Format described at the next lowest address. If the second format 
is not supported by the Source, then the Source should continue looking until it finds a 
supported format, with earlier formats being preferred over later ones. The Source may also 
use other criteria to decide between formats listed in the EDID, such as the criteria listed in 


item c. 


—*™ 


c) If the Source needs to transform the Video Format, it is recommended that transformations 
be made in the following order of precedence, in order to minimize video artifacts. 


i. Image cropping where applicable. (Note: Content that requires a small fractional vertical 
“downscale”, like 1920x1088 @ 60Hz to 1920x1080 @ 60Hz, should simply be cropped. 
Cropping is commonly required when content originates from a video codec format 
(e.g., ISO/IEC 13818-2 [112]) encoded with a vertical size of 1088 lines. In this case, the 
Source generally crops the bottom 8 lines of the originally coded content prior to 
outputting it in a 1080i/1080p format.) 


ii. Horizontal upscale but no frame rate conversion (e.g., 1440x1080 @ 60Hz to 1920x1080 
@ 60Hz or 704x480 @ 59.94Hz to 720x480 @ 59.94Hz) 


iii. Vertical & horizontal upscale but no frame rate conversion (e.g., 720x576 @ 50Hz to 
1280x720 @ 50HZz) 


iv. Vertical & horizontal downscale but no frame rate conversion (e.g., 1280x720 @ 50Hz to 
720x480 @ 50Hz) 


v. Any frame rate conversion (e.g., 720x576 @ 50Hz to 720x480 @ 59.94Hz) 
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d) The Source should maintain video content in its original color space if the Sink accepts that 


e) 


color space 


i. If the Sink accepts video content in YCgCr color space and the Source receives or 
generates video content in the same YCgCr color space, the Source should simply pass- 
through the video content in that color space (see Source Pass-Through Mode, Section 
7.2.2). If the Source is additionally required to blend RGB encoded graphics planes (e.g., 
Closed Captions and Electronic Program Guide data) with the video content, it is 
preferable for the Source to convert the graphics planes to the YCgCr color space of the 
video content prior to blending. 


ii.lf the Sink only accepts video content in RGB color space the Source should perform a 
YCgCr to RGB color space conversion after all image enhancement processes (e.g., 
scaling, interlacing, deinterlacing, noise reduction, frame rate conversion, etc.) have 
been applied. 


Sources capable of sending InfoFrames are required (per Section 6.4) to send accurate 
information regarding any video transformation done in the Source, via an Auxiliary 
InfoFrame (AVI), provided the Sink accepts InfoFrames. 


F.3.5 Errors Reading the EDID 


a) 
b) 


c) 


If an EDID read fails (i.e., incorrect checksum), the Source should attempt to re-read the 
EDID. 

If after numerous attempts, the EDID read still fails, the Source may utilize portions of the 
data that seem valid. 

If the EDID is not at all decipherable, the Source should generate one of the default Sink 
Video Formats defined in Section 3.2. The Source should avoid transmitting audio across the 
interface. If the Source can determine that the Sink is CTA-861-compliant, then it may 
supply 720X480p or 720x576p since support for this format timing is required in all CTA-861 
conformant Sinks. If the Source can determine the Preferred Picture Aspect Ratio for that 
format, then it should use that Picture Aspect Ratio. If the Source cannot determine that the 
Sink is CTA-861 conformant, then it should output 640x480p if it is capable of that format. If 
it cannot output 640x480p, then it should output 720X480p or 720x576p. 


F.3.6 Video Timing Transition (AVMUTE Recommendation) 


Note: This section only applies to HDMI [110]. 


The Source should wait a minimum of three Video Fields following the assertion of AVMUTE 
before stopping or changing video timing. The Source should also allow sufficient time (e.g., 
typically a minimum of five Video Fields) for the Sink to synchronize to the incoming signal 
before clearing AVMUTE. Following this recommendation helps assure that audio and video 
noise are neither seen nor heard during timing changes and that encryption systems recover 
reliably afterwards. 
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F.4 Guidance for Sinks 


F.4.1 


a) 


b) 


F.4.2 


Valid Read-Only EDID 


As required in Section 7 a Sink indicates support for 640x480p Video Format in the EDID 
Detailed Timing Descriptors and/or the Short Video Descriptors. 

If during the course of operation a Sink modifies the contents of its EDID such that the 
Video Formats previously defined and read by Source have changed, then the Sink 
should indicate the change via a Hot Plug Event. (see Annex A.2.19) 


Ordering of the Video Formats in the EDID 


Ordering of the Video Formats in the VFPDB is critical to assure optimal performance of the 
complete system (assuming that Sources follow the rules described in “Guidance for Sources”). 


a) 


b) 


The first SVR in the VFPDB should be the manufacturer’s most preferred timing, which 
might provide optimal video quality. The second best format in terms of preference 
should be listed as the second SVR, and the third best format should be listed in the 
third position. Subsequent formats, each having lower preference than the preceding 
one, should be listed in subsequent positions, although more than 4-5 formats are not 
practical as Sources will begin to implement their own preferential algorithms. 
Designers should think carefully about the use cases described in the Source guidance 
section of this Annex, and order the Video Formats in the EDID so as to minimize the 
instances in which scaling might occur more than once. See Section 7.2.2 for the rules 
regarding ordering of Video Formats. 


Video formats not supported by the Sink should not be listed in EDID. Consideration of methods 
Sources might employ to determine an appropriate Video Format is advised. 


F.4.3 


Video Identification Code (VIC) Transition 


After receiving an AVI InfoFrame carrying a Video Identification Code (VIC) that is different than 
the preceding VIC, the Sink should execute a mode switch as rapidly as possible, not checking 
the format of video itself, but assuming that the transmitted VIC is correct. This is 
recommended in order to minimize video muting between mode switches. 


a) 


b) 


Just prior to executing a mode switch, the Sink should mute video such that any video 
artifacts that could potentially be displayed during the switch are masked from the user. 
The Sink should un-mute video after the mode switch. 

In addition, the Sink should also support AVMUTE functionality — so that muting may 
be directly controlled by Source commands. 
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ANNEX G INFOPACKET FRAMEWORK (INFORMATIVE) 


Previous versions of CTA-861 defined an InfoPacket data structure that could be used to bundle 
one or more InfoFrames together for transmission across an existing digital interface. The 
InfoPacket mechanism is not used in any current interface and is not expected to be used in any 
future interface and so has been deprecated. 


224 


CTA-861-H 


ANNEX H ACTIVE FORMAT DESCRIPTION (INFORMATIVE) 


This Annex describes the application of Active Format Description for video coded as 
constrained by the Advanced Television Systems Committee system (ATSC) and by the Digital 
Video Broadcast system (DVB). 


H.1 ATSC Active Format Description 


This section is extracted from CTA-CEB16-B Active Format Description (AFD) & Bar Data 
Recommended Practice [106]. 


Figure 12 illustrates the meanings of the bounding rectangles, gray areas, and white circles as 
used in Table 157. Table 157 illustrates the AFD codes expected to be used in North America 
(ATSC System). The meaning of each AFD value is Coded Frame context sensitive and each is 
defined in Table 157. The names used for ATSC systems are intentionally different from those 
used in Europe as the default actions are more specific based on the particular configuration of 
receiving and display equipment. CTA-CEB16-B [106] contains more detailed characterizations 
of the frame contents as it adds Bars that indicate black or gray generated by the receiver 
(either in the decoder or display). CTA-CEB16-B recommends receiver actions upon receipt of 
each code depending on video content which is transmitted to the CTA-861 interface and 
depending on characteristics of the display. 
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Shaded regions lie outside the smallest rectangle 
enclosing the circular regions and indicate active video 


Bounding box represents areas that may be cropped by the receiver without 


the coded frame Mi 


Black regions indicate areas of 
the picture that do not contain 


significant loss to the viewer 


oa A. 


i—— White regions lie inside the smallest rectangle 


useful information and should enclosing the circular regions and indicate the 
be cropped by the receiver area of essential picture information which 


where appropriate 


Definitions: 


Coded Frame 


Coded Frame Aspect 


Ratio 


should always be displayed by all receivers 


Figure 12 - Active Format Illustration (ATSC) 


A Picture within a compressed video stream such as MPEG2 that is coded as a single frame or as two 
fields. 


The Picture Aspect Ratio associated with the Coded Frame of a compressed video stream such as 
MPEG2. It is either 4:3 or 16:9. 


Indicates the portion of the Active Image which may be cropped for optimum display as appropriate to 
the aspect ratio of the display screen 


Indicates a matte, often black, which is transmitted as part of the video Coded Frame to fill the area 
outside the Active Image 
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Table 157 - Illustrated ATSC AFD Coding 


active_format Description 


4:3 Coded Frames 16:9 Coded Frames 


‘0000’ 
‘0001’ 


‘0010’ — ‘0011’ 


No AFD Specified 


Reserved 


Not documented for use in US 


No AFD Specified 
Reserved 


Not documented for use in US 


‘0100’ Greater than Greater than 
16:9 letterbox 16:9 letterbox 
image image 
‘0101’ — ‘0111’ Reserved Reserved 
‘1000’ 4:3 full frame ye Fi 16:9 full frame 
image a \ image 
~~ +Y wN 
nes i 
‘1001’ 4:3 full frame a. 4:3 pillarbox 
image at . image 
‘1010’ 16:9 letterbox 16:9 full frame 
image image 
‘1011’ 14:9 letterbox 14:9 pillarbox 
image image 
‘1100’ Reserved Reserved 
‘1101’ 4:3 full a 4:3 pillarbox 
frame image, image, 
alternative 14:9 alternative 
center 14:9 center 
‘1110’ 16:9 letterbox 16:9 full frame 
image, image, 
alternative 14:9 alternative 14:9 
center center 
‘1111’ 16:9 letterbox 16:9 full frame 
image, image, 
alternative alternative 
4:3 center 4:3 center 
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H.2 DVB Active Format Description 


See Annex B of ETSI TS 101 154 [107] for implementation guidance in DVB systems, portions of 
which are replicated below for the convenience of the reader. 


Figure 13 illustrates the meanings of the bounding rectangles, gray areas, and white circles as 
used in Table 158. Table 158 illustrates the AFD codes expected to be used in Europe (DVB 
System). 


Gray regions that lie outside the smallest rectangle 
enclosing the white regions indicate areas of the picture 
that may be cropped by the receiver without significant 
loss to the viewer 


Bounding box represents 


the coded frame , 


“a ————=——. al ae 


Black regions indicate areas of ; \ 
the picture that do not contain ——<——a The smallest rectangle enclosing the white 
useful information and should regions indicates the area of essential picture 
be cropped by the receiver information which should always be 
where appropriate displayed by all receivers 


Figure 13 - Active Format Illustration (DVB) 


Definitions: 
Coded Frame A Picture within a compressed video stream such as MPEG2 that is coded 
as a Single frame or as two fields. 
Coded Frame The Picture Aspect Ratio associated with the Coded Frame of a 
Aspect Ratio compressed video stream such as MPEG2. It is either 4:3 or 16:9. 
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Table 158 - Illustrated DVB AFD Coding 


illustration of described format 


in 4:3 coded frame in 16:9 coded frame 


_ mvenm | 


- vow | FOE | EY 


e@e 


0100 


box > 16:9 (center) 


1000 


1001 


1010 


1011 


1100 


1101 


1110 


1111 


As the coded frame 


4:3 (center) 
16:9 (center) 


14:9 (center) 


reserved 


4:3 
(with shoot & protect 
14:9 center) 


16:9 


(with shoot & protect 
14:9 center) 


16:9 
(with shoot & protect 
4:3 center) 


~ 
© 
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ANNEX | [ INTENTIONALLY OMITTED] 


ANNEX J [ INTENTIONALLY OMITTED] 
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ANNEX K AUDIO SPEAKER PLACEMENT & CHANNEL ALLOCATION 
COMPATIBILITY (INFORMATIVE) 


CTA-861 follows the speaker label and placement definitions of ISO/IEC 62574 [43]. Please refer 
to Annex Q for speaker labels in CTA-861-F and earlier. 


Table 159 compares the speaker placements of CTA-861 to those of the Rec. ITU-R BS.2051 
[139] and SMPTE ST 2035 [103] standards. There is general agreement between 5.1 channels — 
although the exact speaker label names and abbreviations are slightly different. SMPTE ST 2035 
does not abbreviate names, and channels that have no direct equivalents to CTA-861 are not 
listed. Rec. ITU-R BS.2051 lists several Sound Systems, where System H is the closest to CTA-861 
and ISO/IEC 62574. The other Systems of Rec. ITU-R BS.2051 use variations for some speaker 
labels. 


Table 159 - CTA/ITU/SMPTE Audio Channel Description & Abbreviation Comparison 


BS. 2051 ST 2035 
Label Abbr. (IEC, Abbr. SP Label?3 
861-G and | (861-F and 
—s — 
Front Left M+030 / 
hal = = 


discus 


Front Right 
Left surround / 
ae Left side 
surround / Left 
side 


Right Right surround / 


Surround Right side Surround 
surround / Right 
side 
Low Low frequency Low Freq 
Frequency effects / Left low frequency Effects 
Effects 1 frequency effects-1 
effects 


Back Left Left rear 
surround / Left 
back 
Back Right Right rear 
=r surround / Right 
back 
Front left 
Center centre 
Front Right Front right 
of Center centre 


Back Center 
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Table 159 - CTA/ITU/SMPTE Audio Channel Description & Abbreviation Comparison 
(continued) 


ISO/IEC 62574 and CTA-861 Rec. ITU- Rec. ITU-R BS.2051 
R BS.2051 | Systems A through 
G, I,J 


Abbreviation Abbreviation SP Label?3 Label 
(IEC, 861-G (861-F and 
and later) earlier) 


Rec. ITU-R BS.2051 


SMPTE 
ST 2035 


System H 


Label Label Label 


Low LFE2 


Low Right low LFE2 
Frequency frequency frequency 
Effects 2 effects effects-2 
| M+o90 fo 
SiR | M-o90 | ide i S 


Top Front TpFL 
Left 


Top Front TpFR 
Right 


Top Front TpFC 
Center 


Tpc 


Top Back TpBL 
Left 

Top Back TpBR 
Right 


U+030 / Left top Ltf / Top front TpFL 
U+045 front / Left LH left 
height 
U-030 / Right top Rtf / Top front TpFR 
U-045 front / right 
Right 
height 


U+000 


U+110 / Left top 
U+135 rear / Left 
top back 


U-110 / Right top 
U-135 rear / Right 


Top front TpFC 
centre 


Ltr/ | Top back left TpBL 
Ltb 

Rtr / Top back TpBR 
Rtb right 


iL 
Side right 
C 


>) 
a 


top back 
Top Side Left TpSiL u+0o90 | Top side left TpSiL 
Top Side TpSiR U-090 Top side TpSiR 
Right right 


Top Back TpBC 
Center 


Bottom BtFC 


centre 
Bottom BtFC 
front centre 
front left 


t 
U+180 Centre CH 
oe rere 
B+000 Centre Cbf 
bottom 


Front Center 


Bottom BtFL 
Front Left 


FLH 
FRH 
FCH 
TC 
FLW 
RW 


Front Right front right 
Wide 
Wide 


33 Rec. ITU BS.2051 SP Labels are denoted by the initial of the layer name (Top, Upper, Middle and Bottom) and the three-digit 
median azimuth angle. In some systems of BS.2015, functional identical speakers have slightly different angles. In those cases, 
this table lists all SP labels that apply to the speaker function. 


NO 
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Table 160 compares the channel number assignments of CTA-861 for CA=0x00..0x31 to the Rec. 
ITU-R BS.2051 [139] and SMPTE ST 2035 [103] standards. Here again, there is general 
agreement between the 5.1 channels except for the FC and LFE channels, which are swapped. 


Note: CTA-861 with CA=OxFE or OxFF does not have fixed channel assignments and is not 
included in this table. Rec. ITU-R BS.2051 only lists a channel order, but no explicit 
enumeration. 


Table 160 - CTA/ITU/SMPTE Audio Channel Assignment Comparison 


Channel CTA-861 with Rec. ITU-R BS.2051 Rec. ITU-R SMPTE ST 2035 
CA=0x00-0x31 BS.2051 (System (Cases 11¢c — 
Systems A System F Systems G, H) and ISO/IEC 
through E land J 
C 


1 (L of pair 1) Left 
LFE 


3 (L of pair 2) LFE1 
4 (R of pair 2) a 


Left Surround 


2(Rofpair1) | FR 


L 
Cc 
ir2) | FCF 
5 (L of pair 3) LS, BC Ls 
6 (R of pair 3) PRS Rs Right Surround 
Ltf 
i Rtf 


7 (L of pair 4) BL, BC, FLc, TpFL Secondary audio 
TpFC, FLw signals 

8 (R of pair 4) BR, FRc, TpFR LB Rrs Secondary audio 
TpC, TpFC, FRw signals 


FL 
FR 
FC 
RS 
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ANNEX L VIDEO TIMING EXAMPLES (INFORMATIVE) 


This section gives three examples showing how tabular data from Table 1 and Table 2 is applied 
to the generalized waveforms of Figure 1, Figure 2, and Figure 5 for selected Video Timings. In 
these examples, all variables are replaced by specific values either taken directly from the 
tables or calculated using table values. Values for all of the line numbering variables are given in 
the table attached to the lower-left of each figure. These values also replace the respective 
variables in the figure. 


Bottom Line 


Dimensional values in pixel clocks, except where (lines) noted. 
Letters a, b, c, ... represent line numbers. 


Figure 14 - General Progressive Example for Video ID Codes 2 & 3 (720x480p @ 60 Hz) 
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le 
Top Line 


Enable 


Data kK? (linesy___*§ 5 (lines) ___15 (lines) | ° 


Data 
Enable 


Figure 15 - General Interlace Example for Video ID Code 5 (1920x1080i @ 60 Hz) 
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Top Line . 
23 (lines) 5 (lines) 57 (lines) 


+2004 
r an a " Pion east 


VSYNC 


Field 2: 85 (lines) 


540 (lines) 


/ / 


, Bottom Line 


22.5 (lines) 5 (lines) 2 57.5 (lines) 


Dimensional values in pixel clocks, except where (lines) noted. 
Letters a, b, c, ... represent line numbers. 


es SSC~—SSC*d 


Figure 16 - Special Interlace Example for Video ID Code 39 (1920x1080i-1250 Vtotal @ 50 Hz) 
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ANNEX M AFD BAR DATA CONVERSION EXAMPLES (INFORMATIVE) 


This section provides AFD Bar Data conversion examples. The input Bar Data is taken from two 
examples given in Annex B of SMPTE ST 2016-1. Each example is worked below to demonstrate 
the proper calculation of equivalent CTA-861 Bar Data. 


M.1 Converting 720p 2.4:1 Letterbox Bar Data 


The first example (B.1) is a progressive scan 720p Video Format with 2.4:1 centered letterbox 
(93-line horizontal Bar at top, 533-line Active Image, and 94-line horizontal Bar at bottom) with 
Bar Data top_bar_flag=1, bottom_bar_flag=1, left_bar_flag=0O and right_bar_flag=0, 
line_number_end_of_top bar=118, and line_number_start_of_bottom_bar=652. 

SMPTE ST 2016-1 Bar flags top_bar_flag=1 and bottom_bar_flag=1 indicate that horizontal Bar 
Data is present and that Bar Data values line_number_end_of_top_ bar and 
line_number_start_of_bottom_bar need to be converted to equivalent CTA-861 InfoFrame Bar 
Data values ETB and SBB using the equation from Table 28 as follows: 

ETB = line_number_end_of_top_bar - Ln - Vsync - Vback + 1=118-1-5-20+1=93 

SBB = line_number_start_of_bottom_bar-Ln- Vsync - Vback + 1 =652-1-5-20+1=627 
Since horizontal Bars are present (top _bar_flag=1 or bottom_bar_flag=1), B1=1. 


Since SMPTE ST 2016-1 left Bar flag indicates that no left vertical Bar is present 
(left_bar_flag=0), CTA-861 InfoFrame left Bar Data ELB is set to a special value as follows: 


ELB =0 

Since SMPTE ST 2016-1 right Bar flag indicates that no right vertical Bar is present 
(right_bar_flag=0), CTA-861 InfoFrame right Bar Data SRB is set to a special value as follows: 
SRB = Hactive + 1 = 1280 + 1 = 1281. 

Since neither vertical Bars are present (left_bar_flag=0 and right_bar_flag=0), BO=O. 


M.2 Converting 1080i 2.4:1 Letterbox Bar Data 


The second example (B.2) is an interlaced scan 1080i Video Format with 2.4:1 centered 
letterbox (140-line horizontal Bar at top, 800-line Active Image, and 140-line horizontal Bar at 
bottom) with Bar Data top_bar_flag=1, bottom_bar_flag=1, left_bar_flag=0, right_bar_flag=0, 
line_number_end_of_top bar=653, and line_number_start_of_bottom_bar=491. 


SMPTE ST 2016-1 Bar flags top_bar_flag=1 and bottom_bar_flag=1 indicate that horizontal Bar 
Data is present and that Bar Data values line_number_end_of_top_ bar and 

line _number_start_of_bottom_bar need to be converted to equivalent CTA-861 InfoFrame Bar 
Data values ETB and SBB using equations from Table 27 as follows: 


Since 653 > [1 + (1080 / 2)] and 1080i is not “480 Interlaced”, use Field 2 “Other Interlaced” 
equation for ETB calculation. 
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ETB = 2 * [line_number_end_of_top_bar - Ln - Vfront - 2 * (Vsync + Vback) - (Vactive / 2)] 
=2 * [653-1-2-2 * (5 +15) - (1080 / 2)] = 140 


Since 491 <= [1 + (1080 / 2)] and 1080i is not “480 Interlaced”, use Field 1 “Other Interlaced” 
equation for SBB calculation. 


SBB = 2 * [line _number_start_of_bottom_bar - Ln - Vsync - Vback + 1] -1 
=2*[491-1-5-15+1]-1=941 
Since horizontal Bars are present (top_bar_flag=1 or bottom_bar_flag=1), B1=1. 


Since SMPTE ST 2016-1 left Bar flag indicates that no left vertical Bar is present 
(left_bar_flag=0), CTA-861 InfoFrame left Bar Data ELB is set to a special value as follows: 


ELB =0 


Since SMPTE ST 2016-1 right Bar flag indicates that no right vertical Bar is present 
(right_bar_flag=0), CTA-861 InfoFrame right Bar Data SRB is set to a special value as follows: 


SRB = Hactive + 1 = 1920+ 1 = 1921. 
Since neither vertical Bars are present (left_bar_flag=0 and right_bar_flag=0), BO=O. 
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ANNEX N VIDEO FORMAT STRUCTURE (INFORMATIVE) 
This section provides a graphical representation of a Video Format. 


Width Dimension 


Height Dimension = Picture Aspect Ratio 


Picture (Total Image) 


Active Pixels Width Dimension 


Bar Pixel Blank Pix) | 
YY Content Pixe Active Line 

©) 
& 
r= 
Height Dimension Fsyae Active Image te 
© 
5 

mS Blanking Line 
O 


Vertical-Blanking 
Blank Pixel 


Figure 17 - Video Format Structure 
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ANNEX O SYNC, PIXEL, AND INTERFACE-SPECIFIC DATA CLOCK RELATIONSHIPS 
(INFORMATIVE) 


This section provides a graphical representation of the relationships between CTA-861’s Pixel 
Clock, Sync, Active Pixels, Unique Active Pixels, and a hypothetical interface-specific data clock 
for various combinations of chroma sampling (4:4:4, 4:2:2, 4:2:0), Component Depth (8-bit, 10- 
bit, 12-bit, 16-bit per component), and pixel repetition (PR). 


Data Clock 4:4:4 or 4:2:0 16-bit Deep Color 
Data Clock 4:4:4 or 4:2:0 12-bit Deep Color 
Data Clock 4:4:4 or 4:2:0 10-bit Deep Color 


Data Clock 4:4:4 or 4:2:0 8-bit, 4:2:2 10-bit or 12-bit 


Interface Vevelopment Urganization Standard 


Pixel Clock 


FU UU U UU UU 

FUL UU UU 

ed ee Sync (aligned with Pixel Clock) 
ATTESTED ELS EE] enor 
ae ae Cc Unique Active Pixels 4:4:4 or 4:2:2 PR=3 


Figure 18 - Active Pixels, Unique Active Pixels, Pixel Clock, Data Clock, and Sync Relationships 


Consumer Electronics Association CEA-361 
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Table 161 - Pixel Clock Frequency Modification 
[Mode Actual Pixel Clock Frequency 


2D 4:4:4 Table 1 Listed Pixel Clock Frequency (VIC) 
2D 4:2:2 Table 1 Listed Pixel Clock Frequency (VIC) 


2D 4:2:0 Table 1 Listed Pixel Clock Frequency (VIC) / 2 
3D 4:4:4 or 4:2:2 Table 1 Listed Pixel Clock Frequency (VIC) * 2 
3D 4:2:0 Table 1 Listed Pixel Clock Frequency (VIC) 


241 


CTA-861-H 


ANNEX P CALCULATION OF MAXCLL AND MAXFALL (NORMATIVE) 


The values of MaxCLL and MaxFALL shall be calculated as follows: 


P.1 MaxCLl 
CalculateMaxCLL() 


1 
set MaxCLL = O 


for each ( frame in the sequence ) 


{ 
set frameMaxLightLevel = 0 
for each ( pixel in the active image area of the frame ) 
{ 
convert the pixel’s non-linear (R’,G’,B’) values to linear values (R,G,B) 
calibrated 
to cd/m? 
set maxRGB = max(R,G,B) 
if((maxRGB>frameMaxLightLevel ) 
set frameMaxLightLevel = maxRGB 
} 
if(frameMaxLightLevel>MaxCLL ) 
set MaxCLL = frameMaxLightLevel 
I 


return MaxCLL 


P.2 MaxFALL 
CalculateMaxFALL() 


{ 
set MaxFALL = 0 


for each ( frame in the sequence ) 
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{ 
set runningSum = 0 
for each ( pixel in the active image area of the frame ) 
{ 
convert the pixel’s non-linear (R’,G’,B’) values to linear values (R,G,B) 
calibrated 
to cd/m? 
set maxRGB = max(R,G,B) 
set runningSum = runningSum + maxRGB 
} 
set frameAverageLightLevel = runningSum / numberOfPixelsInActivelmageArea 
if(frameAverageLightLevel>MaxFALL ) 
set MaxFALL = frameAverageLightLevel 
} 


return MaxFALL 
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ANNEX Q CHANGE IN AUDIO SPEAKER NAMES FROM CTA-861-F TO CTA-861-G 
(INFORMATIVE) 


CTA-861 uses the speaker naming convention defined in ISO/IEC 62574 [43]. This Annex defines 
the relationship between the naming conventions used in CTA-861 versus previous revisions. 
Note that some positions defined are new and don't have an equivalent position in previous 
versions of CTA-861. 


Table 162 - Speaker Label Changes from CTA-861-F to CTA-861-G 


ISO/IEC 62574 and CTA- _ 


F 


1] 7 
Wir 


es) 
— 


mn 


FRC 


Ke IZ II dial 
O12 lo|m 


8s) 
mM 


4 
(2) 


aa eae 


34 In IEC 62574 [43] labeling, Top Channels (Tp) are equivalent to Height (H) in various naming conventions. 
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ANNEX R HDR DYNAMIC METADATA SYNTAX TYPE 1 (NORMATIVE) 


R.1 Scope 


A display management (DM) message contains metadata in order to provide dynamic 
information that can be employed by the display to adapt the delivered HDR imagery to the 
capability of the display device. The information conveyed in this DM message corresponds to 
the metadata specified in SMPTE ST 2094-1 [53], SMPTE ST 2094-10 [54] and 

SMPTE ST 2086 [42]. 


This annex specifies a syntax for the carriage of ST 2094-10 [54] Application #1 metadata for 
type_1 hdr_metadata_version value Ox0. This syntax is used for carriage of this metadata over 
the CTA-861 interface. It may also be used in an SEI message. Future versions of CTA-861 may 
specify the data format for future versions of type 1 HDR metadata. 


R.2 Definitions 


Refer to Rec. ITU-T H.265 [52], Sections 5.2 "Arithmetic operators", 5.8 "Mathematical 
functions" and 7.2 “Specification of syntax functions and descriptors”; which includes 
definitions for the functions Round() and Clip3(). 


For this annex, sequence’ refers to one or more frames with identical metadata values. A 
sequence may consist of continuous pictorial content, starting and ending at an editorial cut 
point, or of a single frame. 


R.3 Display Management Message 


The data format for the DM message is defined in Table 163 - DM_data(), Table 164 - 
ext_dm_data_block(), and Table 165 - ext_dm_data_block_payload(). 
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Table 163 - DM_data() 


DM_data() { Descriptor 
reserved 1 


reserved 2 


reserved 3 


reserved 4 


display_primaries_x[ 0 | 


display_primaries_y[ 0 ] 


display_primaries_x[ 1 | 


display_primaries_y[ 1 ] 


display_primaries_x[ 2 | 


display_primaries_y[ 2 ] 


white_point_x 


white_point_y 


max_display_mastering luminance 


min_display_mastering luminance 


reserved _15 


reserved_16 


reserved 17 


reserved 18 


reserved 19 


reserved_20 


reserved 21 


reserved 22 


reserved _23 


reserved 24 


reserved 25 


reserved 26 


reserved 27 


reserved 28 


reserved 29 


reserved_30 


reserved 31 


reserved _32 


reserved _33 


reserved 34 


reserved _35 


num_ext_blocks 
if( num_ext_blocks ) { 
while( !byte_aligned() ) 


dm_alignment_zero_bit 
for( i = 0; i< num_ext_blocks; i++ ) { 


ext_dm_data_block() 


reserved_1-—reserved_4 and reserved_15 — reserved_35 are not used. Sources shall set 
reserved_1-—reserved_4 and reserved_15 — reserved_35 to zero. Sinks shall ignore reserved_1 
—reserved 4 and reserved _15-—reserved_35. 
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display_primaries_x[0], display_primaries_y[0], display_primaries_x[1], 
display_primaries_y[1], display_primaries_x[2], display_primaries_y[2], white_point_x, 
white_point_y, max_display_mastering luminance, min_display_mastering luminance are 
defined in Rec. ITU-T H.265 [52], Section D.3.28, "Mastering display colour volume SEI message 
syntax’. When max_display_mastering luminance is zero, sinks shall not use 
max_display_mastering luminance and min_display_mastering luminance as luminance 
values. 


Table 164 - ext_dm_data_block() 


ext_dm_data_block() { Descriptor 


ext_block_length 

ext_block_level 

ext_dm_data_block_payload( ext_block_length, ext_block_level ) 
} 


Table 165 - ext_dm_data_block_payload() 
ext_dm_data_block_payload( ext_block_length, ext_block_level ) { Descriptor 


ext_block_len_bits = 8 * ext_block_length 

ext_block_use_bits = 0 

if( ext_block_level == 1 ) { 
min _PQ 
max_PQ 
avg PQ 
ext_block_use_bits += 36 

} 

if( ext_block_level == 2 ) { 
target_max_PQ 
trim_slope 
trim_offset 
trim_power 
trim_chroma_weight 
trim_saturation_gain 
ms_weight 
ext_block_use_bits += 85 

} 

if( ext_block_level == 3 ) { 
min_PQ_ offset 
max_PQ_ offset 
avg PQ_offset 
ext_block_use_bits += 36 

} 

if( ext_block_level == 5 ) { 
active_area_left_offset 
active_area_right_offset 
active _area_top_offset 
active_area_bottom_offset 
ext_block_use_bits += 52 

} 

while( ext_block_use_bits++ < ext_block_len_bits ) 
ext_dm_alignment_zero_bit 


} 
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The parameter values used in this Annex are independent of the input pixel bit depth and 
represent units in absolute luminance or intensity. All 12-bit PQ encoded parameters included 
in this Annex are used to process pixels with up to 12-bit components. These PQ encoded 
parameters are computed as shown in Annex A.2 of ST 2084 [41]. 


num_ext_blocks specifies the number of extended metadata blocks. The value shall be in the 
range of 0 to 254, inclusive. 


dm_alignment_zero_bit shall be equal to 0. dm_alignment_zero_bit is not present if 
num_ext_blocks is equal to O. 


ext_block_length| i | is used to derive the size of the i-th extended metadata block payload in 
bytes. The value shall be in the range of 0 to 1023, inclusive. ext_block_length is not present if 
num_ext_blocks is equal to 0. 


ext_block_levell i ] specifies the level of payload contained in the current extended metadata 
block. The value shall be in the range of 0 to 255, inclusive. The corresponding extended display 
mapping metadata block types are defined in Table 166 below. If ext_block_level is not present, 
it shall be inferred to be O. 


Table 166 - Definition of extended metadata block type 


ext_block_level extended display mapping metadata block type 
Ra aaa eee 
a Level 1 Metadata — Content Range 


rs nr ta dato — Content Range Off8S 
Ss Reserved 


Reserved 


If there is more than one extension block with ext_block_level equal to 1, decoder shall only 
use the latest level 1 extension block transmitted in current frame. If there are more than 16 
extension blocks with ext_block_level equal to 2, decoder shall only use the first 16 level 2 
extension blocks transmitted in current frame. If there is an extension block with 
ext_block_level equal to reserved values, decoder shall ignore that extension block. If there is 
no extension block transmitted in the current frame, the decoder shall fall back to the values of 
level 1 and level 2 extended metadata as specified below. 


min_PQ specifies the minimum luminance value of the current frame sequence in 12-bit PQ 
encoding. The value shall be in the range of 0 to 4095, inclusive. If min _PQ is not present, it 
Shall be inferred to be equal to the 12 bit PQ encoded value of 

min_display_mastering luminance. Note that the 12-bit min _PQ value is calculated as follows: 


min_PQ = Clip3(0, 4095, Round(Min * 4095)), 


where Min is MinimumPqencodedMaxrgb as defined in section 6.1.3 of ST 2094-10 [54]. 


max_PQ specifies the maximum luminance value of the current frame sequence in 12-bit PQ 
encoding. The value shall be in the range of 0 to 4095, inclusive. If max_PQ is not present, it 
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Shall be inferred to be equal to the 12 bit PQ encoded value of 
max_display_mastering luminance. Note that the 12-bit max_PQ value is calculated as follows: 


max_PQ = Clip3(0, 4095, Round(Max * 4095)), 


where Max is MaximumPqencodedMaxrgb as defined in section 6.1.5 of ST 2094-10 [54]. 


avg PQspecifies the midpoint luminance value of the current frame sequence in 12-bit PQ 
encoding. The value shall be in the range of 0 to 4095, inclusive. If avg PQ is not present, it shall 
be inferred to be equal to the 12 bit PQ encoded value of (min_display_mastering luminance + 
max_display_mastering luminance) / 2. Note that the 12-bit avg PQ value is calculated as 
follows: 


avg_PQ = Clip3(0, 4095, Round(Avg * 4095)), 


where Avg is AveragePgencodedMaxrgb as defined in section 6.1.4 of ST 2094-10 [54]. 


target_max_PQ specifies the maximum luminance value of a target display in 12-bit PQ 
encoding. The value shall be in the range of 0 to 4095, inclusive. If target_max_PQ is not 
present, it shall be inferred to be equal to the 12 bit PQ encoded value of 
max_display_mastering luminance. target_max_PQ is the PQ encoded value of 
TargetedSystemDisplayMaximumLuminance as defined in section 10.4 of ST 2094-1 [53]. If 
there is more than one extension block with ext_block_level equal to 2, no two of those blocks 
Shall have the same target_max_PQ. 


trim_slope specifies the slope metadata. The value shall be in the range of 0 to 4095, inclusive. 
If trim_slope is not present, it shall be inferred to be 2048. Note that the 12-bit slope value is 
calculated as follows: 


trim_slope = Clip3(0, 4095, Round((S - 0.5) * 4096)), 


where S is the ToneMappingGain as defined in section 6.2.3 of ST 2094-10 [54]. 


trim_offset specifies the offset metadata. The value shall be in the range of O to 4095, inclusive. 
If trim_offset is not present, it shall be inferred to be 2048. Note that the 12-bit offset value is 
calculated as follows: 


trim_of fset = Clip3(0, 4095, Round((0+0.5) * 4096)), 


where O is the ToneMappingOffset as defined in section 6.2.2 of ST 2094-10 [54]. 


trim_power specifies the power metadata. The value shall be in the range of 0 to 4095, 
inclusive. If trim_power is not present, it shall be inferred to be 2048. Note that the 12-bit 
power value is calculated as follows: 


trim_power = Clip3(0, 4095, Round((P - 0.5) * 4096)), 


where P is the ToneMappingGamma as defined in section 6.2.4 of ST 2094-10 [54]. 


trim_chroma_weight specifies the chroma weight metadata. The value shall be in the range of 
0 to 4095, inclusive. If trim_chroma_weight is not present, it shall be inferred to be 2048. Note 
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that the 12-bit chroma weight value is calculated as follows: 
trim_chroma_weight = Clip3(0, 4095, Round((CW+0.5) * 4096)), 


where CW is the ChromaCompensationWeight as defined in section 6.3.1 of ST 2094-10 [54]. 


trim_saturation_gain specifies the saturation gain metadata. The value shall be in the range of 
0 to 4095, inclusive. If trim _saturatioin_gain is not present, it shall be inferred to be 2048. Note 
that the 12-bit saturation gain value is calculated as follows: 


trim_saturation_gain = Clip3(0, 4095, Round((SG+0.5) * 4096)), 


where SG is the SaturationGain as defined in section 6.3.2 of ST 2094-10 [54]. 


ms_weight specifies the multiscale weight metadata. The value shall be in the range of -1 to 
4095, inclusive. If ms_weight is not present, it shall be inferred to be 2048. Where ms_ weight is 
equal to -1, the bit stream indicates ms_weight is unspecified. The 13-bit multiscale weight 
value is calculated as follows: 


ms_weight = -1 OR Clip3(0, 4095, Round(MS * 4096)), 


where MS is the ToneDetailFactor as defined in section 6.4.2 of ST 2094-10 [54]. 


min_PQ_offset specifies the offset to the minimum luminance value of the current frame 
sequence in 12-bit PQ encoding. The value shall be in the range of 0 to 4095, inclusive. If 
min_PQ_ offset is not present, it shall be inferred to be 2048. Note that the 12-bit 
min_PQ_offset value is calculated as follows: 


min_PQ offset = Clip3(0, 4095, Round((Min_Offset + 0.5) * 4096 )), 


where Min_ Offset is MinimumPqencodedMaxrgbOffset as defined in section 6.1.6 of 
ST 2094-10 [54]. 


max_PQ_offset specifies the offset to the maximum luminance value of the current frame 
sequence in 12-bit PQ encoding. The value shall be in the range of 0 to 4095, inclusive. If 
max _PQ_ offset is not present, it shall be inferred to be 2048. Note that the 12-bit 
max_PQ_ offset value is calculated as follows: 


max_PQ_ offset = Clip3(0, 4095, Round((Max_Offset + 0.5) * 4096)), 


where Max_ Offset is MaximumPqencodedMaxrgbOffset as defined in section 6.1.8 of 
ST 2094-10 [54]. 


avg PQ_ offset specifies the offset to the midpoint luminance value of the current frame 
sequence in 12-bit PQ encoding. The value shall be in the range of 0 to 4095, inclusive. If 

avg PQ_offset is not present, it shall be inferred to be 2048. Note that the 12-bit avg PQ_offset 
value is calculated as follows: 


avg_PQ offset = Clip3(0, 4095, Round((Avg_Offset + 0.5) * 4096)), 
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where Avg_Offset is AveragePqencodedMaxrgbOffset as defined in section 6.1.7 of 
ST 2094-10 [54]. 


active_area_left_offset, active_area_right_offset, active_area_top_ offset, 
active_area_bottom_offset specify the active area of the current frame, in terms of a 
rectangular region specified in frame coordinates for active area. The values shall be in the 
range of 0 to 8191, inclusive. See also UpperLeftCorner and LowerRightCorner definitions in ST 
2094-1. 


If active _area_left_offset, active _area_right_offset, active _area_top_ offset, 
active_area_bottom_offset are not present, they shall be inferred to be O. 


The coordinates of top left active pixel are derived as follows: 
Xtop left = active _area_left_offset 
Ytop left = active_area_top_offset 


The coordinates of top left active pixel are defined as the UpperLeftCorner in section 9.2 of 
ST 2094-1 [53]. 


The coordinates of bottom right active pixel are derived as follows: 
Xbottom right = XSize - 1 - active_area_right_offset 
Ybottom right = YSize - 1 - active_area_bottom_offset 


where Xsize is the horizontal resolution of the current frame and Ysize is the vertical resolution 
of the current frame. Xbottom right is greater than Xtop left ANA Ybottom right is greater than Ytop left. 


The coordinates of bottom right active pixel are defined as the LowerRightCorner in section 9.3 
of ST 2094-1 [53]. 


ext_dm_alignment_zero_bit shall be equal to 0. 
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ANNEX S HDR DYNAMIC METADATA SYNTAX TYPE 4 (NORMATIVE) 


S.1 Scope 


The SMPTE ST 2094 suite of documents defines metadata for use in color volume transforms of 
content. The metadata are content-dependent and can vary scene-by-scene or frame-by-frame. 
The metadata are intended to transform High Dynamic Range and Wide Color Gamut 
(HDR/WCG) source content for presentation on a display having a smaller color volume than 
the source content’s mastering display. 


SMPTE ST 2094-40 Application #4 [55] specifies the content-dependent color volume transform 
metadata items for Application #4. This color volume transform defines scene-based metadata 
to reproduce the original intent of the creator of High Dynamic Range (HDR) and Wider Color 
Gamut (WCG) image essence on a display having a smaller color volume, even in the case that 
the mastering display and the targeted system display may both have practical limits on the 
peak luminance they can produce. 


This annex specifies the syntax and semantics for the carriage of SMPTE ST 2094-40 

Application #4 [55] metadata. For type_4 hdr_metadata_ version value OxO, the syntax and 
semantics are as defined below without the constraints described in Section S.4. For 

type _4 hdr_metadata_version values 0x1 and 0x2, the syntax and semantics are as shown 
below and are constrained as described in Section S.4. type_4 hdr_metadata_version values of 
OxO and Ox1 indicate that the Sink is capable of receiving metadata with an application_mode of 
0x00. Atype_4 hdr_metadata_ version value of 0x2 indicates that the Sink is capable of 
receiving metadata with an application_mode of 0x00 or 0x01. The syntax specified in Table 
167 - user_data_registered_itu_t_t35, with the semantics specified in Section S.3, is used for 
carriage of this metadata over the CTA-861 interface, and may also be used in an SEI message. 
Future versions of CTA-861 may specify the syntax for future versions of type 4 metadata. 


S.2 User_data_registered_itu_t_t35 SEI message syntax for ST 2094-40 [55] 


Table 167 - user_data_registered_itu_t_t35 defines the message syntax for the full set of 
features specified by ST 2094-40. Additional constraints are specified in Section S.4. 
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Table 167 - user_data_registered_itu_t_t35 


for( w= 1; w< num_windows; w++ ) { 


] ee 
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Table 167 - user_data_registered_itu_t_t35 (continued) 


targeted_system_display_maximum_luminance 

targeted _system_display_actual_peak_luminance_flag 

if( targeted _system_display_actual_peak_luminance_flag ) { 
num_rows_targeted_system_display_actual_peak_luminance 
num_cols targeted _system_display_actual_peak_luminance 
for( i=0;i< num_rows_targeted_system_display_actual_ peak luminance; i++ ) 

for( j = 0; j<num_cols targeted _system_display_actual_peak_luminance; j++ ) 
targeted_system_display_actual_peak_luminance|[ i ][ j | 


for( w =0; w< num_windows; w++ ) { 

for( i = 0; i < 3; i++) 
maxscl[ w ][ i] 

average _maxrgb[ w |] 

num_distributions[ w ] 

for( i= 0; i < num_distributions[ w ]; i++ ) { 
distribution_index[ w ][i ] 
distribution_values|[ w ][ i] 


fraction_bright_pixels[ w ] 


mastering display_actual_peak_luminance_flag 
if( mastering display_actual_peak_luminance_flag ) { 
num_rows_mastering_ display_actual_peak_luminance 
num_cols_ mastering _display_actual_peak_luminance 
for( i=0;i<num_rows_ mastering display _actual_peak_luminance; i++ ) 
for( j = 0; j<num_cols_ mastering display_actual_ peak luminance; j++ ) 
mastering display _actual_peak_luminance[ i ][ j ] 


for( w= 0; w< num_windows; w++ ) { 
tone_mapping_flag[ w ] 
if( tone_mapping flag[ w ] ) { 
knee_point_x[ w ] 
knee_point_y[ w ] 
num_bezier_curve_anchors|[ w | 
for( i = 0; i < num_bezier_curve_anchors[ w ]; i++ ) 
bezier_curve_anchors[ w ][ i] 


color_saturation_mapping flag[ w ] 
if( color_saturation_mapping_flag[ w ]}) { 
color_saturation_weight[ w ] 


S.3 User_data_registered_itu_t_t35 SEI message semantics for ST 2094-40 [55] 


This SEI] message provides information to enable color volume transformation of the 
reconstructed color samples of the output pictures. The input to the indicated color volume 
transform process is the linearized RGB color components of the source content. 
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The information conveyed in this SEI message is intended to be adequate for purposes 
corresponding to the use of SMPTE ST 2094-40 [55]. Additional constraints are specified in 
Section S.4. 


itu_t_t35_country_code shall be a byte having a value specified as a country code by Rec. ITU-T 
T.35 Annex A [56]. The value shall be OxB5. 


itu_t_t35_terminal_provider_code shall be a fixed 16-bit field. The value shall be Ox003C. 


itu_t_t35_terminal_provider_oriented_code shall be a 16-bit code. The value shall be as 
specified in Table 168. 


Table 168 - Interpretation of the itu_t_t35_terminal_provider_oriented_code 


itu_t_t35_terminal_provider_oriented_code Indicated value 
Ox0000 Unspecified 


0x0001 ST 2094-40 [55] 
0x0002 — OxFFFF 


application_identifier identifies an application and its defining document in the ST 2094 suite. 
Application_identifier shall be set to 4. 


application_mode shall indicate the ApplicationVersion of SMPTE ST 2094-40 [55] as specified 
in Table 169. 


Table 169 - Interpretation of application_mode 


application_mode Indication 
ApplicationVersion = 0 


ApplicationVersion = 1 
Ox02 — OxFF 


num_windows indicates the number of processing windows. The first processing window shall 
be for the entire picture. (See S.4 Additional Constraints.) 


window_upper_left_corner_x[ w ] specifies the x coordinate of the top left pixel of the w-th 
processing window. The value of window_upper_left_corner_x[ w ] shall not exceed 65535. 
(See S.4 Additional Constraints.) 


window_upper_left_corner_y[ w ] specifies the y coordinate of the top left pixel of the w-th 
processing window. The value of window_upper_left_corner_y[ w ] shall not exceed 65535. 
(See S.4 Additional Constraints.) 


window_lower_right_corner_x[ w ] specifies the x coordinate of the bottom right pixel of the 
w-th processing window. The value of window_lower_right_corner_x| w ] shall not exceed 
65535. (See S.4 Additional Constraints.) 


window_lower_right_corner_y[ w ] specifies the y coordinate of the bottom pixel of the w-th 
processing window. The value of window_lower_right_corner_y[ w ] shall not exceed 65535. 
(See S.4 Additional Constraints.) 
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center_of_ellipse_x[ w ] specifies the x coordinate of the center position of the concentric 
internal and external ellipses of the elliptical pixel selector in the w-th processing window. The 
value of center_of_ellipse_x[ w | shall be in the range of 0 to (width of Picture - 1), inclusive, 
and in multiples of 1 pixel. (See S.4 Additional Constraints.) 


center_of_ellipse_y[ w ] specifies the y coordinate of the center position of the concentric 
internal and external ellipses of the elliptical pixel selector in the w-th processing window. The 
value of center_of_ellipse_y[ w | shall be in the range of 0 to (height of Picture - 1), inclusive, 
and in multiples of 1 pixel. (See S.4 Additional Constraints.) 


rotation_angle[ w ] specifies the clockwise rotation angle in degree of arc with respect to the 
positive direction of the x-axis of the concentric internal and external ellipses of the elliptical 
pixel selector in the w-th processing window. The value of rotation_angle| w ] shall be in the 
range of 0 to 180, inclusive, and in multiples of 1. (See S.4 Additional Constraints.) 


semimajor_axis_internal_ellipse[ w ] specifies the semi-major axis value of the internal ellipse 
of the elliptical pixel selector in amount of pixels in the w-th processing window. The value of 
semimajor_axis_internal_ellipse[ w ] shall be in the range of 1 to 65535, inclusive, and in 
multiples of 1 pixel. (See $.4 Additional Constraints.) 


semimajor_axis_external_ellipse[ w ] specifies the semi-major axis value of the external ellipse 
of the elliptical pixel selector in amount of pixels in the w-th processing window. The value of 
semimajor_axis_ external ellipse[ w ] shall not be less than semimajor_axis_internal_ellipse[ w 
]. The value of semimajor_axis_external_ellipse[ w | shall be in the range of 1 to 65535, 
inclusive, and in multiples of 1 pixel. (See S.4 Additional Constraints.) 


semiminor_axis_external_ellipse[ w ] specifies the semi-minor axis value of the external ellipse 
of the elliptical pixel selector in amount of pixels in the w-th processing window. The value of 
semiminor_axis_external_ellipse[ w | shall be in the range of 1 to 65535, inclusive, and in 
multiples of 1 pixel. (See S.4 Additional Constraints.) 


overlap_process_option[ w ] is an enumerator that indicates one of the two methods of 
combining rendered pixels in the w-th processing window in an image with at least one 
elliptical pixel selector. For overlapping elliptical pixel selectors in an image, 

overlap process option[ w ] shall have the same value. overlap process option[ w | =0 shall 
indicate the Weighted Averaging method and overlap_process_option[ w | = 1 shall indicate the 
Layering method as described in Annex B of reference [55]. (See S.4 Additional Constraints. ) 


targeted_system_display_maximum_luminance specifies the nominal maximum display 
luminance of the targeted system display. This parameter shall represent a value in the range of 
0 to 10000 cd/m’, inclusive. Based on the value of application mode and the coded value of 
this parameter, the resolution of targeted_system_display_maximum_luminance shall be as 
specified in Table 170 
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Table 170 - Resolution of targeted_system_display_maximum_luminance 


application_mode Coded value 
0x0000000 - 0x0002710, inclusive 


0x0002711 — 0x5F5E100, inclusive 0.0001 cd/m? 
0x0000000 — 0x0002710, inclusive 


When application_mode has a value of 0x00, this parameter should be in the range of 
0x0000000 to 0x0002710, inclusive (i.e., decimal 0 to 10000, inclusive) and in units of 1 cd/m?; 
however, Sources that comply with a previous version of this standard may code this parameter 
in units of 0.0001 cd/m. 


targeted_system_display_actual_peak_luminance_flag enables the targeted system display 
actual peak luminance feature of SMPTE ST 2094-40 [55]. (See S.4 Additional Constraints.) 


num_rows_targeted_system_display_actual_peak_luminance specifies the number of rows in 
the targeted _system_display_actual_ peak luminance array. The value of 
num_rows_targeted_system_display_actual_peak_luminance shall be in the range of 2 to 25, 
inclusive. (See S.4 Additional Constraints.) 


num_cols_targeted_system_display_actual_peak_luminance specifies the number of columns 
in the targeted _system_display_actual_ peak luminance array. The value of 
num_cols_targeted_system_display_actual_peak_luminance shall be in the range of 2 to 25, 
inclusive. (See S.4 Additional Constraints.) 


targeted _system_display_actual_peak_luminance[ i ][ j ] specifies the normalized actual peak 
luminance of the targeted system display. The value of 
targeted_system_display_actual_peak_luminance|[ i ][ j ] shall be in the range of O to 15, 
inclusive, representing a range of 0 cd/m? to the value of 
TargetedSystemDisplayMaximumLuminance as defined in clause 7.2 of SMPTE ST 2094-40 [55]. 
(See S.4 Additional Constraints.) 


maxscl[ w ][ i] specifies the maximum of the i-th color component of linearized RGB values, as 
defined in clause 4.6 of SMPTE ST 2094-40 [55], in the w-th processing window in the scene (as 
defined in clause 4.6 of SMPTE ST 2094-40 [55]). The value of maxscl[ w ][ i] shall be in the 
range of 0 to 100000, inclusive, representing a range of 0 to 1. maxscl[ w ][ 0], maxscl[ w ][ 1 J, 
and maxscll w ][ 2 ] shall correspond to the R, G, and B color components, respectively. A 
maxscl[ w | value of { 0, 0, O } indicates that the calculated maximum linearized RGB values are 
not available. 


average _maxrgb[ w ] specifies the average of linearized maxRGB values, as defined in clause 
4.5 of SMPTE ST 2094-40 [55], in the w-th processing window in the scene. The value of 
average_maxrgb[ w ] shall be in the range of 0 to 100000, inclusive, representing a range of 0 to 
1. 


num_distributions[ w ] indicates the number of linearized maxRGB values at given percentiles 
in the w-th processing window in the scene. (See S.4 Additional Constraints.) 
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distribution_index[ w ][ i] specifies the interpretation of the corresponding 
distribution_values| w ][ i] value and represents DistributionMaxRGBPercentages [55]. The 
value of distribution_index[ w ][ i] shall be in the range of 0 to 99, inclusive. (See S.4 Additional 
Constraints.) 


distribution_values[ w ][ i ] represents DistributionMaxRGBPercentiles [55]. The value of 
distribution. values| w J[ i] shall be in the range of 0 to 100,000, inclusive, representing a range 
of 0 to 1. (See S.4 Additional Constraints.) 


fraction_bright_pixels[ w | is unused and constrained to a value of 0. (See S.4 Additional 
Constraints.) 


mastering display_actual_peak_luminance_flag enables the mastering display actual peak 
luminance feature of ST 2094-40. (See S.4 Additional Constraints.) 


num_rows_mastering display_actual_peak_luminance specifies the number of rows in the 
mastering display_actual_ peak luminance array. The value of 

num_rows_mastering display_actual_ peak luminance shall be in the range of 2 to 25, 
inclusive. (See S.4 Additional Constraints.) 


num_cols_mastering display_actual_peak_luminance specifies the number of columns in the 
mastering display_actual_peak_luminance array. The value of 

num_cols_ mastering display _actual_ peak luminance shall be in the range of 2 to 25, inclusive. 
(See S.4 Additional Constraints.) 


mastering display_actual_peak_luminance[ i ][ j ] specifies the normalized actual peak 
luminance of the mastering display used for mastering the image essence. The value of 
mastering display _actual_peak_luminance| i || j ] shall be in the range of 0 to 15, inclusive, 
representing a range of 0 cd/m’ to the value of Maximum Display Mastering Luminance (as 
defined in SMPTE ST 2086 [42]). (See S.4 Additional Constraints.) 


tone_mapping_flag[ w ], when set to 1, indicates that the metadata for the tone mapping 
function in the w-th processing window is present. When set to O, it indicates that the 
metadata for the tone mapping function in the w-th processing window is not present. 


knee_point_x[ w ] specifies the x coordinate of the separation point between the linear part 
and the curved part of the tone mapping function. The value of knee_point_x[ w | shall be in 
the range of 0 to 4095, inclusive, representing a range of 0 to 1. 


knee_point_y[ w ] specifies the y coordinate of the separation point between the linear part 
and the curved part of the tone mapping function. The value of knee_point_y[ w | shall be in 
the range of 0 to 4095, inclusive, representing a range of 0 to 1. 


num_bezier_curve_anchors|[ w ] indicates the number of the intermediate anchor parameters 
of the tone mapping function in the w-th processing window. (See S.4 Additional Constraints.) 


bezier_curve_anchors|[ w ][ i] specifies the i-th intermediate anchor parameter of the tone 
mapping function in the w-th processing window in the scene. The value of 
bezier_curve_anchors|[ w || i] shall be in the range of 0 to 1023, inclusive, where 1023 
corresponds to an intermediate anchor parameter value of 1.0. 
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color_saturation_mapping_flag[ w ] enables the color saturation mapping feature of ST 2094- 
40. (See S.4 Additional Constraints.) 


color_saturation_weight[ w ] specifies a number that shall adjust the color saturation gain in 
the w-th processing window in the scene. The value of color_saturation_weight[ w | shall be in 
the range of 0 to 63/8, inclusive, and in multiples of 1/8. The default value shall be 1. (See S.4 
Additional Constraints.) 


Note: Definitions of the metadata items and terms used in this section of the document 
are provided in reference [53] and [55]. A color volume transform method using this 
message is described in Annex B of reference [55]. 


S.4 Additional Constraints 


For type_4 hdr_metadata_version values 0x1 and Ox2, the following additional constraints 
Shall apply: 


Table 171 - Additional constraints 


num_windows 


1 


window_upper_left_corner_x[ w ] 


Not used 


window_upper_left_corner_y[ w | 


Not used 


window_lower_right_corner_x[ w ] 


Not used 


window_lower_right_corner_y[ w ] 


Not used 


center_of_ellipse_x[ w] 


Not used 


center_of_ellipse_y[ w] 


Not used 


rotation_angle[ w | 


Not used 


semimajor_axis_internal_ellipse[ w |] 


Not used 


semimajor_axis_external_ellipse[ w | 


Not used 


semiminor_axis_external_ellipse[ w ] 


Not used 


overlap_process_ option w ] 


Not used 


targeted_system_display_actual_peak_luminance_flag 


0 


num_rows_targeted_system_display_actual_peak_luminance 


Not used 


num_cols_targeted_system_display_actual_peak_luminance 


Not used 


targeted_system_display_actual_peak_luminance| i ][ j | 


Not used 


The value of num_distributions[ w ] 


9 


distribution _index[ 0 ][ i | 


See Table 172 


distribution_values|[ 0 ][ i ] 


See below 


fraction_bright_pixels[ w ] 


0 


mastering display_actual_peak_luminance_flag 


0 


num_rows_mastering display_actual_ peak luminance 


Not used 


num_cols_ mastering display_actual_peak_luminance 


Not used 


mastering display _actual_peak_luminance[ i ]| j] 


Not used 


num_bezier_curve_anchors[ w ] 


0 to 9, inclusive 


color_saturation_mapping_flag[ w ] 


0 


color_saturation_weight[ w | 
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The value of distribution _index[ 0 || i] is as defined in Sections 8.5.2 through 8.5.4 in SMPTE ST 
2094-40 [55] and shall be fixed as shown in Table 172. 


Table 172 - Values of distribution_index[ 0 ][ i ] 


distribution_index[ 0 ][ 0 ] 
distribution _index[ 0 ][ 1 ] 
distribution_index[ 0 ][ 2 ] 
distribution_index[ 0 ][ 3 ] 


distribution_index[ 0 ][ 4 ] 
distribution_index[ 0 ][ 5 ] 
distribution_index[ 0 ][ 6 ] 
distribution_index[ 0 ][ 7 ] 
distribution index[ 0 ][ 8 ] 


The value of distribution values] O ][ i] shall be as specified in Sections 8.5.2 through 8.5.4 of 
SMPTE ST 2094-40 [55]. 
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ANNEX T GRAPHICS OVERLAY FLAG (NORMATIVE) 


T.1 Scope 


The Graphics Overlay Flag indicates that the video picture to which the current HDR Dynamic 
Metadata applies has been significantly changed. This typically occurs when a set-top-box or 
video playback device has added a Graphics Overlay or has presented content related to an 
interactive application. When this occurs, a display that applies the transmitted HDR Dynamic 
Metadata to the video picture might cause clipping or other improper reproduction of the 
image. When the HDR Dynamic Metadata varies and a large Graphics Overlay has a fixed value, 
this can cause the overlay to change appearance over time, which can be perceived as an 
unintended “breathing” of the image. The Graphics Overlay Flag indicates to the Sink device 
that the HDR Dynamic Metadata does not necessarily represent the characteristics of the 
delivered video images. This Annex specifies a syntax for the carriage of the Graphics Overlay 
Flag for graphics flag overlay_version value Ox0. 


T.2 Graphics Overlay Flag Syntax 
The syntax of the Graphics Overlay Flag shall be as specified in Table 173: 
Table 173 - Overlay Flag Syntax 


ee 


graphics _o 
F17=0 F16=0 F15=0 F14=0 F13=0 F12=0 F11=0 verlay_ 
flag 


graphics_overlay_flag identifies when the video picture has been altered such that the HDR 
Dynamic Metadata is unlikely to represent the characteristics of the delivered video images. A 
value of 0 shall indicate that the HDR Dynamic Metadata represents the characteristics of the 
delivered video images. A value of 1 shall indicate that the HDR Dynamic Metadata does not 
necessarily represent the characteristics of the delivered video images. The default value shall 
be 0. 


A Sink shall not use HDR Dynamic Metadata for tone mapping when the value of the Graphics 
Overlay Flag is equal to 1, except for during a period immediately following the transition of the 
value of the Graphics Overlay Flag from 0 to 1, during which the Sink may apply a smooth 
transition from the use of HDR Dynamic Metadata for tone mapping to an alternative method 
of tone mapping. 


A Sink may use HDR Dynamic Metadata, when available, for tone mapping when the value of 
the Graphics Overlay Flag is equal to 0. When the value of the Graphics Overlay Flag transitions 
from 1 to O, the Sink may apply a smooth transition from its current tone mapping basis to the 
use of HDR Dynamic Metadata for tone mapping. 
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When sending a Graphics Overlay Flag Extended InfoFrame, a Source shall set the Graphics 
Overlay Flag to 0 when no graphics overlay has been added to the frame to which the 
InfoFrame applies and may set the Graphics Overlay Flag to 1 when a Graphics Overlay has 
been added. 


The Source continues sending HDR Dynamic Metadata whenever the Graphics Overlay Flag is 
being sent (regardless of whether it is set to O or 1) in order for smooth transitions to be 
supported. 


T.3 Graphics Overlay Flag Usage 


When the Graphics Overlay Flag has a value of 1, the Sink is expected to use a static method of 
tone mapping, for example: ST 2086 metadata, MaxCLL or some other means. 


Note that if the Sink were to transition abruptly between dynamic and static methods of tone 
mapping when the Graphics Overlay Flag changes state, the result might be displeasing to 
viewers. A smooth transition of a period between 0.5 and 2 seconds has been shown to provide 
satisfactory results. 


Ideally, a Source would only set the Graphics Overlay Flag to a value of 1 for Graphics Overlays 
that are large, opaque, and have high-luminance content. Conversely, in the ideal case, a 
Source would set the Graphics Overlay Flag to a value of O when the Graphics Overlay is small, 
semi-transparent, or lacks high-luminance content, or when the Graphics Overlay consists of 
captions or subtitles only. However, it is not always possible for the Source to determine the 
nature of the Graphics Overlay and the decision of when to set the flag can be subjective; 
therefore, the conditions under which a Source should set the Graphics Overlay Flag is not 
specified. 
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